Proyecto de Título RPA - Final

INSTITUTO PROFESIONAL SANTO TOMÁS
SEDE San Joaquín
Proyecto de Título
Automatización de procesos mediante RPA
Alumno: Marco Soruco Hurtado

Profesor Guía: Claudio Carmona
Carrera: Ingeniería en Informática
Fecha: 10/11/2017
i
NOTA OBTENIDA:
ii
Dedicatoria
El presente proyecto va dedicado a Cynthya mi mujer y pilar fundamental en mi vida,

por instarme siempre a ser mejor, por su apoyo y comprensión en cada momento de
familia sacrificado en este camino.
A mis hijos Franco y Millaray por ser mi principal motivación ya que al verlos siento
aún más ganas de trabajar fuertemente para mejorar. Son la razón de todo este
esfuerzo.
A mis padres y familia, por sus consejos y ayuda.
Y agradezco a mis abuelos, por darme su apoyo incondicional y sin límites, desde
que comencé este camino, hace 33 años atrás.
A todos ustedes, con amor, se merecen esto y mucho más.
iii
Índice General
Presentación del Proyecto de Título………………………………………………….. i
Hojas de Calificación…………………………………………………………………… ii
Dedicatoria……………………………………………………….……………………… iii
Agradecimientos……………………………………………………….……………….. iii
Índice General………….……………………………………………………………….. iv
Índice de Tablas………………………………………………………………………… v
Índice de Figuras……………………………………………………………………...... vi
Glosario, abreviaturas y simbología………………………………………………….. vii
Resumen………………………………………………………………………………… ix
I. FUNDAMENTOS……………………………………………………………………. 1
I.1 Introducción……………………………………………………...………………. 1
I.2 Objetivos del Proyecto…………………………………………...………….…. 2
II. DESARROLLO DEL PROYECTO…………………………………..……………. 3
II.1 Descripción de la empresa, institución o área TI………………..…….……. 3
II.2 Descripción de las tareas desarrolladas en la práctica profesional………. 4
II.3 Planificación y Metodología del Proyecto…………………...………………. 5
II.4 Descripción del Desarrollo del Proyecto…………………...………………. 9
III. PRODUCTO FINAL……………………...…………………………………………. 31
III.1 Presentación del Problema………………………………..…………………. 31
III.2 Desarrollo del Problema………………………..………………………………. 37
IV. ASPECTOS COMPLEMENTARIOS…………………..…………………………. 61
Bibliografía………………………………………………...……………………………. 61
Anexos…………………………………………………………………..………………. 63
iv
Índice de Tablas
Tabla 1 - Sprints Planificación Proyecto .................................................................................... 5

Tabla 2 - TMO Actividades ...................................................................................................... 32
Tabla 3 - Tabla Equivalencia Excel – Formulario Web ............................................................ 35
Tabla 4 - Diccionario de Datos ............................................................................................... 43
Tabla 5 - Caso de Uso Login .................................................................................................... 46
Tabla 6 - Caso de Uso Ingresar Actividad ................................................................................ 47
Tabla 7 - Caso de uso obtiene empresa .................................................................................. 48
Tabla 8 - Caso de Uso Actualizar Actividad ............................................................................. 49
Tabla 9 - Caso de Uso Ver Actividad....................................................................................... 50
Tabla 10 - Caso de Uso Buscar Actividades ............................................................................. 51
Tabla 11 - Caso de Uso Bandeja de Actividades ..................................................................... 52
Tabla 12 - Caso de Uso Selecciona actividad a ejecutar ......................................................... 53
Tabla 13 - Caso de Uso Crear Usuario ..................................................................................... 54
Tabla 14 - Caso de Uso Cambiar Contraseña .......................................................................... 55
v
Índice de Figuras
Ilustración 1 Carta Gantt Implementación ............................................................................... 5

Ilustración 2 Flujo de un Sprint ................................................................................................. 7
Ilustración 3 - Arquitectura Plataforma RPA ............................................................................. 9
Ilustración 4 Modelo Vista Controlador.................................................................................. 13
Ilustración 5 Rol metadata ...................................................................................................... 14
Ilustración 6 Data Binding ....................................................................................................... 15
Ilustración 7 Componentes Angular2 ..................................................................................... 16
Ilustración 8 - Flujos UIPath Studio ......................................................................................... 23
Ilustración 9- Esquema Funcionamiento Máquinas Virtuales ................................................ 25
Ilustración 10 - Ramas en Git .................................................................................................. 27
Ilustración 11 - Top 5 Actividades ........................................................................................... 33
Ilustración 12 - Formulario Agendamiento Venta .................................................................. 35
Ilustración 13 - Formulario Agendamiento Portabilidad ........................................................ 36
Ilustración 13 - Diagrama BPMN Agendamiento Equipos ...................................................... 37
Ilustración 14 - Modelo de Datos............................................................................................ 38
Ilustración 15 - Casos de Uso Sistema Web ............................................................................ 44
Ilustración 16 - Casos de uso - API Rest .................................................................................. 45
Ilustración 17 - Diagrama de Estados...................................................................................... 56
Ilustración 18 - Arquitectura Servidores ................................................................................. 56
Ilustración 19 - Pantalla de Ingreso......................................................................................... 56
Ilustración 20 Ingreso de Actividad......................................................................................... 56
Ilustración 21 - Bandeja de Actividades de Usuario ............................................................... 56
Ilustración 22 - Actualización de Actividad ............................................................................. 56
Ilustración 23 - Detalle actividad ............................................................................................ 56
Ilustración 24 Dashboard Actividades .................................................................................... 56
vi
Glosario, abreviaturas y simbología
Middleware: Middleware es software que se sitúa entre un sistema operativo y las

aplicaciones que se ejecutan en él. Básicamente, funciona como una capa de
traducción oculta para permitir la comunicación y la administración de datos en
aplicaciones distribuidas. A veces, se le denomina “plumbing” (tuberías), porque
conecta dos aplicaciones para que se puedan pasar fácilmente datos y bases de
datos por una “canalización”. El uso de middleware permite a los usuarios hacer
solicitudes como el envío de formularios en un explorador web o permitir que un
servidor web devuelva páginas web dinámicas en función del perfil de un usuario.
Back End: Es el software que se encuentra del lado del servidor, es decir, lenguajes
de programación como PHP, Python, .Net, Java, etc, es lo que se encarga de
interactuar con bases de datos, verificar manejo de sesiones de usuarios, en
resumen, se encarga de “servir” todas las vistas que el FrontEnd despliega.
Front End: El frontend son todas aquellas tecnologías que corren del lado del cliente,
es decir, todas aquellas tecnologías que corren del lado del navegador web,
generalizándose más que nada en tres tecnologías, Html , CSS Y JavaScript.
Framework: Un framework, entorno de trabajo o marco de trabajo2 es un conjunto

estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática
particular que sirve como referencia, para enfrentar y resolver nuevos problemas de
índole similar.
API: Una API es un conjunto de funciones y procedimientos que cumplen una o

muchas funciones con el fin de ser utilizadas por otro software. Las siglas API vienen
del inglés Application Programming Interface. En español sería Interfaz de
Programación de Aplicaciones. Es una capa de abstracción de un software.
Patrón de Diseño: En programación a veces nos encontramos con ciertos problemas

que se repiten a lo largo de nuestra experiencia, como puede ser, el caso típico, hacer
una clase que pueda controlar múltiples tipos de conexiones, o una clase que una vez
instanciada (creado un objeto) no se puede volver a crear un nuevo objeto. Pues bien,
los patrones de diseño, son unos diseños básicos de clases e interfaces, aplicables a
cualquier lenguaje orientado a objetos (c++, c#, java, php, javascript, etc), para
solucionar ciertos tipos de problemas.
vii
MVC: El MVC o Modelo-Vista-Controlador es un patrón de arquitectura de software
que, utilizando 3 componentes (Vistas, Models y Controladores) separa la lógica de
la aplicación de la lógica de la vista en una aplicación. Es una arquitectura importante
puesto que se utiliza tanto en componentes gráficos básicos hasta sistemas
empresariales; la mayoría de los frameworks modernos utilizan MVC (o alguna
adaptación del MVC) para la arquitectura.
ORM: Object-Relational mapping, o lo que es lo mismo, mapeo de objeto-relacional,

es un modelo de programación que consiste en la transformación de las tablas de una
base de datos, en una serie de entidades que simplifiquen las tareas básicas de
acceso a los datos para el programador.
TMO: Tiempo medio de Operación corresponde al tiempo que demora un ejecutivo

en ejecutar una actividad o solicitud, desde que la toma hasta que responde al cliente
una vez ejecutada.
SLA: Service Level Agreement, como concepto es un acuerdo entre cliente y

proveedor, para acordar un nivel de calidad asociado al servicio acordado, pueden
ser distinto factores por sí solos o un conjunto de estos, como tiempo, calidad, dinero,
etc.
viii
INSTITUTO PROFESIONAL SANTO TOMÁS
Ingeniería en Informática
San Joaquín
10-11-2017
Plataformas RPA
Autor: Marco Antonio Soruco Hurtado

Profesor Guía: Claudio Carmona
Palabras Claves: RPA, Robot, Automatización, Usuario
El proyecto desarrollara una plataforma integral para la automatización de procesos

mediante RPA (Robotic Process Automation). Los beneficios que se obtienen al
automatizar en un área los procesos internos que son voluminosos y repetitivos, son
considerables, obteniendo mejor exactitud, velocidad, agilidad, flexibilidad, etc. Todos
estos beneficios conllevan a que la ejecución de los procesos automatizados por los
robots RPA, se lleven a cabo de una forma óptima y robusta.
Entrando a un ámbito más técnico, implementaremos una plataforma compuesta de

una arquitectura integral conformada por tres componentes, el primero será una
interfaz web de cara a los usuarios, la cual se encargará de recibir las peticiones a
ejecutar por el robot RPA y mostrar el resultado de las ejecuciones. El segundo
componente dentro de nuestra arquitectura será una API REST la cual utilizaremos
como nexo de comunicación entre los usuarios finales y los robots RPA. El último y
principal componente será el Robot RPA como tal, el cual se encargará de ejecutar la
actividad seleccionada (Agendamiento de Equipos) posterior a la realización de un
estudio que nos entregó el tiempo demandado por todas las actividades que realiza
el área de Administración Ventas.
Analizaremos los pasos que componen la ejecución de un agendamiento de Equipos,

que sistemas se deben intervenir, que decisiones son más críticas y requieren
obligatoriamente la intervención de un humano y viceversa, que pasos son los
repetitivos y se podemos delegarlos al robot.
ix
I. FUNDAMENTOS
I.1 INTRODUCCIÓN
Para poder comprender el valor que aportan las plataformas RPA, comenzaremos
definiendo que es un proceso BackOffice. Se denomina tareas o procesos
BackOffice, al conjunto de tareas administrativas asociadas a los procedimientos
internos que son realizados antes o después de la interacción con el cliente.
Actualmente existen diversas tareas BackOffice que son voluminosas y repetitivas

dentro de las organizaciones, estos procesos pueden corresponder a distintas áreas
de las empresas (RRHH, Servicio al cliente, finanzas, etc.) al ser estas tareas
repetitivas y además necesitar pocas reglas o validaciones para su ejecución,
proporcionan el escenario ideal para que puedan intervenir los robots RPA y poder
delegar la ejecución de estas tareas a los robots.
Cuando se habla de robots tendemos a pensar en máquinas pesadas que llevan a

cabo tareas industriales, principalmente en cadenas de montaje. RPA extrapola ese
concepto de automatización a los modelos puramente informáticos, por tanto,
hablamos de robots de software.
La capacidad de procesamiento de los equipos computacionales modernos, así como

sus altas posibilidades de conexión e internet, están permitiendo el auge de este tipo
de tecnología de automatización. Entre las razones de este auge, podemos
mencionar: procesamiento rápido de información, capacidad de conectar diferentes
sistemas informáticos entre sí, generar documentos, actualizar bases de datos, enviar
mails y traspasar datos entre aplicaciones.
1
I.2 OBJETIVOS DEL PROYECTO
A continuación, se mencionan los objetivos que se busca cumplir con este proyecto
de título.
Objetivo general
El objetivo general del proyecto consiste en que por medio de los robots RPA poder
contribuir en el ahorro de tiempo y disminución de la carga laboral de los ejecutivos.
Para esto, analizaremos cual es la actividad que demanda más tiempo dentro de las
gestiones que realizan los ejecutivos de la Empresa 2080 Sistemas y Servicios,
teniendo identificada la actividad más crítica (que ocupa más tiempo del equipo de
trabajo) procederemos a automatizar lo máximo posible por medio de los robots RPA
(ingreso a sistemas externos, lecturas Excel etc.), para así delegar a estos robots la
mayor parte del tiempo que utilizan los ejecutivos en gestionar esta actividad.
Objetivos Específicos
A. El objetivo principal del proyecto consiste en implementar una plataforma integral,

bajo una arquitectura tecnológica capaz de soportar la comunicación entre los
usuarios finales y los robots RPA.
B. Implementar una interfaz web que permita a los usuarios ingresar solicitudes a los
robots RPA, para que estas sean ejecutadas.
C. Implementar un cuadro de mando web, con reportes encargados de mostrar el

resultado de las ejecuciones realizadas por el robot.
D. Implementar una API Rest que será utilizada por el robot, como interfaz de
comunicación hacia nuestro sistema Web.
E. Implementar un robot RPA, que será el encargado de ejecutar todas las

solicitudes que sean ingresadas por la Web.
2
II DESARROLLO DEL PROYECTO
II.1 Descripción de la empresa, institución o área TI
La empresa en la que se llevará a cabo este proyecto de título será 2080 Servicios y
Sistemas S.A.
Esta empresa es proveedora de Servicios de Outsourcing de Procesos, de Soluciones

de Integración y Desarrollo, y Soporte Operativo de Soluciones Tecnológicas. Cuenta
con una amplia experiencia en Servicios de Cobranza Masiva y Especializada,
Atención de Clientes (Presencial y Remoto) y Back Office a Empresas, así como en
la implementación de Servicios de Diseño, Desarrollo de software, VoIP,
Infraestructura TI y Soporte de Aplicaciones Informáticas.
Trabaja de manera flexible y responsable, adaptándose con agilidad a las cambiantes

demandas del Negocio, y su personal cuenta con la experiencia, conocimiento y
certificaciones necesarias, para garantizar el éxito de nuestros proyectos y asegurar
que el cliente obtenga el máximo de valor del servicio o solución adquirida.
Busca relaciones de largo plazo con sus clientes basada en la confianza, calidad de
servicio y en la obtención de resultados, en donde pueda aportar valor al negocio final
del cliente, mejorando sus procesos de negocio y aumentando sus ventajas
competitivas.
3
II.2 Descripción de las tareas desarrolladas en la práctica profesional
Encargado de realizar el levantamiento, desarrollar y gestionar proyectos, para áreas

internas que prestan servicio a Telefónica Chile. Teniendo participación en todo el
ciclo de vida de estos, desde la toma de requerimientos hasta su instalación en
producción.
Estos proyectos, principalmente consisten en automatizar, optimizar y garantizar el

correcto funcionamiento de las funciones más críticas que son realizadas por el
personal de estas áreas internas.
Funciones específicas del puesto:
A continuación, se detallan las funciones que deben ser realizadas en el puesto de

Ingeniero de Desarrollo.
- Toma de requerimientos con clientes de áreas internas y externas (Telefónica

Chile)
- Análisis y diseño de la solución
- Estimación de plazos y recursos
- Diseño y modelamiento de base de datos
- Implementación de solución principalmente en PHP, utilizando el framework
Cakephp en su versión 2.3.
- Jefatura de proyectos, gestionando los recursos correspondientes para
cumplir con los plazos determinados.
- Elaboración y ejecución de consultas en bases de datos, Postgresql 9.2
- Elaboración y ejecución de consultas en bases de datos, Oracle
- Ejecución de Pruebas
- Correcciones y mejoras en desarrollos que ya se encuentran en producción.
- Desarrollo de integraciones con otras plataformas (Sharepoint, Exchange,
Correos, etc).
- Elaboración de documentación (documento de requerimientos, diagramas
BPNM, estimaciones, casos de prueba, etc).
- Conocimientos básicos en administración de sistemas Linux (Centos)
- Configuración de Servidor Web Apache
4
II.3 Planificación y Metodología del Proyecto
Planificación del proyecto
La fecha de inicio para la implementación de nuestro proyecto será el 01 de diciembre

del 2017, esta implementación tendrá una duración de 25 días hábiles, por lo que el
proyecto será entregado el día 04-01-2018.
En la implementación de nuestro proyecto, dividiremos nuestro proyecto en tres hitos

principales, donde cada uno de los hitos corresponderá a un Sprint dentro de la
metodología Scrum. En la siguiente tabla, se detallan los hitos más relevantes junto
a la duración de cada uno de estos y la fecha su fecha de término.
Hito Principal Duración Inicio Fin

Implementación Interfaz Web 10 días 01-12-17 14-12-17
Implementación API REST 5 días 15-12-17 21-12-17
Implementación Robot 10 días 22-12-17 04-01-18
Tabla 1 - Sprints Planificación Proyecto
Finalmente se adjunta la imagen de la carta Gantt del proyecto, en la cual se detalla

cada uno de los hitos y sub hitos correspondientes a la implementación de nuestro
proyecto.
Ilustración 1 Carta Gantt Implementación – Fuente: Elaboración Propia
5
Metodología para gestionar el proyecto
En la actualidad los proyectos informáticos se desarrollan bajo contextos muy

versátiles, son más complejos y las exigencias de los clientes son muy variables y
con una incertidumbre elevada.
Es este escenario el que ha propiciado el auge de las metodologías, ya que este tipo
de metodologías nos ofrecen más flexibilidad en la gestión de los proyectos.
La metodología que utilizaremos en este proyecto será Scrum. A continuación,

detallaremos en que consiste y como aplicar esta metodología.
Scrum es un método para trabajar en equipo a partir de iteraciones o Sprints. Así

pues, Scrum es una metodología ágil, por lo que su objetivo será controlar y planificar
proyectos con un gran volumen de cambios de última hora, en donde la incertidumbre
sea elevada.
Se suele planificar por semanas. Al final de cada Sprint o iteración, se va revisando

el trabajo validado de la anterior semana. En función de esto, se priorizan y planifican
las actividades en las que invertiremos nuestros recursos en el siguiente Sprint.
La metodología Scrum se centra en ajustar sus resultados y responder a las

exigencias reales y exactas del cliente. De ahí, que se vaya revisando cada
entregable, ya que los requerimientos van variando a corto plazo. El tiempo mínimo
para un Sprint es de una semana y el máximo es de cuatro semanas.
Entre las principales características de la metodología Scrum, destaca que es un

desarrollo incremental en lugar de la clásica planificación del desarrollo completo de
un producto o servicio. Sus equipos de trabajo se caracterizan por ser auto-
organizados. Y se centra en el producto final, en la calidad del mismo.
Además, en la metodología Scrum se solapan diferentes fases de desarrollo, en lugar

de llevar a cabo una planificación secuencial o de cascada.
6
Etapas de un Sprint
Cada Sprint puede tener una serie de eventos o etapas. Los más comunes son:
1. Reunión para la planificación del Sprint. En ella, se divide el tiempo de duración

del Sprint, así como el objetivo y entregable del mismo. Además, el equipo de
desarrollo deberá saber cómo realizarlo. Muy parecido a lo que llamamos reunión
de Kick off y que puedes descubrir en este curso gratis y online de gestión de
proyectos.
2. Scrum diario: Se basa en poner en común y sincronizar actividades para elaborar

el plan del día.
3. Trabajo de desarrollo durante el Sprint: Nos aseguramos que los objetivos se

están cumpliendo, que no se producen cambios que alteran el objetivo del Sprint
y se mantiene un feedback constante con el cliente o dueño del proyecto.
4. Revisión del Sprint: Reunión con el cliente o dueño del proyecto, en la que se
estudia y revisa el Product Backlog del Sprint. Se definen los aspectos a cambiar,
en caso necesario, de mayor valor o probables para planificarlo en el siguiente
Sprint.
5. Retrospectiva del proyecto: Oportunidad del equipo de desarrollo para mejorar

su proceso de trabajo y aplicar los cambios en los siguientes Sprints.
Ilustración 2 Flujo de un Sprint – Fuente: http://madbricks.co/scrum-kanban/
7
Roles
La metodología Scrum tiene unos roles y responsabilidades principales, asignados a

sus procesos de desarrollo. Estos son:
• Project Owner: Se asegura de que el proyecto se esté desarrollando acorde con

la estrategia del negocio. Escribe historias de usuario, las prioriza, y las coloca en
el Product Backlog.
• Master Scrum o Facilitador: Elimina los obstáculos que impiden que el equipo
cumpla con su objetivo.
• Development team Member: Los encargados de crear el producto para que

pueda estar listo con los requerimientos necesarios. Se recomienda que sea un
equipo multidisciplinar, de no más de 10 personas. Sin embargo, empresas como
Google disponen de unos 15.000 desarrolladores trabajando en una rama del
código. Y con una metodología Scrum. La automatización en el testeo explica
sobre por qué este gran volumen en el equipo.
8
II.4 Descripción del Desarrollo del Proyecto
Para la construcción de este proyecto se necesita utilizar e integrar diversas

herramientas tecnológicas como lenguajes de programación, frameworks, protocolos,
estándares, etc.
Nuestra plataforma de robots RPA, se encuentra compuesta por cuatro componentes

principales, estos son:
• Interfaz Web
• API
• Capa de Persistencia
• Robot RPA
Los componentes nombrados anteriormente, se comunican entre ellos según el

siguiente diagrama:
Ilustración 3 - Arquitectura Plataforma RPA - Fuente: Elaboración Propia
9
A continuación, detallaremos cada uno de estos componentes y el rol que cumplirán
dentro de nuestra plataforma.
• Interfaz Web: Como en la mayoría de los sistemas, un sistema web permite

la comunicación entre los usuarios y los módulos del sistema, permitiendo el ingreso
de datos (actividades en nuestro caso) por parte de los usuarios, los cuales son
procesados bajo la lógica de negocios y son almacenados en la capa de persistencia.
Además, permite al usuario visualizar la reportería asociada a las solicitudes
ingresadas bajo distintos criterios, fechas, estado de las solicitudes, usuarios de
ingreso, etc.
Esta interfaz web será implementada utilizando el framework de front-end Angular 2
el cual utilizaremos para comunicarnos con el middleware (API Rest) y para desplegar
los datos obtenidos desde el backend.
• API: Dentro de este componente se concentrará toda la lógica de negocio para

la operación de nuestro sistema, el procesamiento de datos, cálculos, búsquedas, etc.
Se comunicará tanto con la interfaz web como con los robots RPA.
Los estándares que serán utilizados por esta API son REST para las peticiones (GET,
POST, PUT, etc.) y JSON para la obtención o envío de datos hacia los demás
componentes.
Esta API será implementada utilizando el framework PHP Laravel5, el cual utiliza el
patrón modelo vista controlador para separar la lógica de negocio con los datos.
• Persistencia: Esta capa es la encargada de realizar las operaciones CRUD

en nuestra base de datos, la versión del servidor de base de datos que utilizaremos
será MariaDB.
Laravel proporciona un ORM (Object-relational Mapping), que es una forma de
mapear los datos que se encuentran en la base de datos almacenados en un lenguaje
de script SQL a objetos de PHP y viceversa, esto surge con la idea de tener un código
portable con el que no tengamos la necesidad de usar lenguaje SQL dentro de
nuestras clases de PHP.
10
• Robot RPA: Este componente corresponde a él o los robots encargados de
ejecutar las actividades ingresadas por los usuarios, que en nuestro proyecto
corresponderán a las de tipo “Aceptación de Ventas”.
Estos robots solicitan una actividad por medio de la API REST, le ejecutan y
posteriormente por medio de la misma API actualizan el estado de la actividad con el
resultado de su ejecución.
Estos robots son el equivalente a un usuario, ingresan datos, utilizan el mouse, a
interfaz gráfica, etc. Por lo que se les debe asignar un “computador” con todos los
componentes, por lo que se le asignará una máquina virtual a cada robot que
queramos que ejecute las actividades.
Los robots RPA serán implementados utilizando UIPath Community edition ya que
proporciona una amplia lista de eventos que pueden ser programados y capturados
con esta herramienta, como leer texto desde una web, leer Excel, enviar hotkeys,
hacer click, doble click, etc.
Y a su vez proporciona una interfaz amigable que facilita el desarrollo de estos los
robots.
11
Descripción Herramientas Utilizadas
A continuación, detallaremos cada una de las tecnologías y herramientas que

utilizamos en la construcción de nuestra plataforma. Describiendo las bondades que
nos ofrece y los motivos por los cuales decidimos utilizarlas.
Laravel 5
Laravel es un framework de código abierto para el desarrollo de aplicaciones web en

PHP 5 que posee una sintaxis simple, expresiva y elegante. Fue creado en 2011 por
Taylor Otwell, inspirándose en Ruby on Rails y Symfony, de los cuales ha adoptado
sus principales ventajas.
Laravel facilita el desarrollo simplificando el trabajo con tareas comunes como la

autenticación, el enrutamiendo, gestión sesiones, el almacenamiento en caché, etc.
Algunas de las principales características y ventajas de Laravel son:
• Está diseñado para desarrollar bajo el patrón MVC (modelo - vista -

controlador), centrándose en la correcta separación y modularización del
código. Lo que facilita el trabajo en equipo, así como la claridad, el
mantenimiento y la reutilización del código.
• Integra un sistema ORM de mapeado de datos relacional llamado Eloquent
aunque también permite la construcción de consultas directas a base de
datos mediante su Query Builder.
• Permite la gestión de bases de datos y la manipulación de tablas desde
código, manteniendo un control de versiones de las mismas mediante su
sistema de Migraciones.
• Utiliza un sistema de plantillas para las vistas llamado Blade, el cual hace
uso de la cache para darle mayor velocidad. Blade facilita la creación de
vistas mediante el uso de layouts, herencia y secciones.
• Facilita la extensión de funcionalidad mediante paquetes o librerías
externas. De esta forma es muy sencillo añadir paquetes que nos faciliten
el desarrollo de una aplicación y nos ahorren mucho tiempo de
programación.
• Incorpora un intérprete de línea de comandos llamado Artisan que nos
ayudará con un montón de tareas rutinarias como la creación de distintos
componentes de código, trabajo con la base de datos y migraciones,
gestión de rutas, cachés, colas, tareas programadas, etc.
Además, Laravel utiliza MVC en su arquitectura, lo que nos facilitará separar la vista
en json para la API y HTML para la web, la lógica de negocio y los modelos ORM.
12
El modelo–vista–controlador (MVC) es un patrón de arquitectura de software que
separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y
el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC
propone la construcción de tres componentes distintos que son el modelo, la vista y
el controlador, es decir, por un lado, define componentes para la representación de la
información, y por otro lado para la interacción del usuario. Este patrón de arquitectura
de software se basa en las ideas de reutilización de código y la separación de
conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones
y su posterior mantenimiento.
Ilustración 4 Modelo Vista Controlador Fuente: https://www.safaribooksonline.com/library/view/laravel-

design-patterns/9781783287987/ch01s02.html
De manera genérica, los componentes de MVC se podrían definir como sigue:
• El Modelo: Es la representación de la información con la cual el sistema opera, por

lo tanto, gestiona todos los accesos a dicha información, tanto consultas como
actualizaciones. Las peticiones de acceso o manipulación de información llegan al
'modelo' a través del 'controlador'.
• El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca

peticiones al 'modelo' cuando se hace alguna solicitud de información (por ejemplo,
editar un documento o un registro en una base de datos). Por tanto, se podría decir
que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo'.
• La Vista: Presenta el 'modelo' y los datos preparados por el controlador al usuario de

forma visual. El usuario podrá interactuar con la vista y realizar otras peticiones que
se enviarán al controlador.
13
Angular
Angular 2 (ahora formalmente Angular, a secas) es un framework completo para

construir aplicaciones en cliente con HTML y Javascript, es decir, con el objetivo de
que el peso de la lógica y el renderizado lo lleve el propio navegador, en lugar del
servidor.
A groso modo, para crear apps utilizando Angular2 se deben seguir los siguientes
pasos:
• Componer plantillas HTML (templates) con el markup de Angular

• Escribir Componentes para gestionar esas plantillas y Directivas que afectan
al comportamiento de los componentes.
• Encapsular la lógica de la aplicación en Servicios
• Definir un módulo principal que le dice a Angular qué es lo que incluye tu app
(otros módulos), y cómo compilarlo y lanzarlo (NgModule).
Podemos identificar los 8 bloques principales de una app con Angular:
• Módulo: Un módulo de Angular, es un conjunto de código dedicado a un

ámbito concreto de la aplicación, o una funcionalidad específica y se define
mediante una clase decorada con @NgModule.
• Componente: Un Componente controla una zona de espacio de la pantalla
que podríamos denominar vista. Un componente es una clase estándar de
ES6 decorada con @Component.
• Template: El template de Angular es HTML, pero decorado con otros
componentes y algunas directivas: expresiones de Angular que enriquecen
el comportamiento del template.
• Metadatos: Informa a Angular como procesar una clase.
Ilustración 5 Rol metadata - Fuente: https://angular.io/guide/architecture
14
• Data Binding: Sin este framework, nosotros seríamos los responsables de
los valores de los datos en los controles HTML y convertir las respuestas de
los usuarios en acciones y actualizaciones de valores. Implementar esta
lógica de push/pull a mano es tedioso, por lo que este componente es el
encargado de realizarlo.
Ilustración 6 Data Binding – Fuente: https://angular.io/guide/architecture
• Directiva: Las plantillas de Angular son dinámicas. Cuando Angular las

renderiza, transforma el DOM de acuerdo a las instrucciones dadas por las
directivas. Una directiva es una clase con un decorator @Directive.
• Servicio: Un servicio es una amplia categoría que puede abarcar cualquier
valor, función o característica que su aplicación necesite. Como, por ejemplo:
(servicio de login, servicio de datos, bus de mensajes, etc.).
• Dependency Injection: Es una forma de suministrar una nueva instancia de una
clase con las dependencias completamente formadas que requiere. La mayoría
de las dependencias son servicios.
Angular usa la inyección de dependencias para proporcionar nuevos
componentes con los servicios que necesitan.
15
En la siguiente imagen podemos ver como se relacionan los elementos descritos
anteriormente dentro de la arquitectura de angular.
Ilustración 7 Componentes Angular2 - Fuente: https://angular.io/guide/architecture
Standard REST
REST, REpresentational State Transfer, es un tipo de arquitectura de desarrollo web

que se apoya totalmente en el estándar HTTP.
REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier
dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y
convencional que otras alternativas que se han usado en los últimos diez años como
SOAP y XML-RPC.
REST se definió en el 2000 por Roy Fielding, coautor principal también de la
especificación HTTP. Podríamos considerar REST como un framework para construir
aplicaciones web respetando HTTP.
Por lo tanto, REST es el tipo de arquitectura más natural y estándar para crear APIs
para servicios orientados a Internet.
Existen tres niveles de calidad a la hora de aplicar REST en el desarrollo de una
aplicación web y más concretamente una API que se recogen en un modelo
llamado Richardson Maturity Model en honor al tipo que lo estableció, Leonard
Richardson padre de la arquitectura orientada a recursos. Estos niveles son:
1. Uso correcto de URIs

2. Uso correcto de HTTP.
3. Implementar Hypermedia.
16
Además de estas tres reglas, nunca se debe guardar estado en el servidor, toda
la información que se requiere para mostrar la información que se solicita debe estar
en la consulta por parte del cliente.
Al no guardar estado, REST nos da mucho juego, ya que podemos escalar mejor sin
tener que preocuparnos de temas como el almacenamiento de variables de sesión e
incluso, podemos jugar con distintas tecnologías para servir determinadas partes o
recursos de una misma API.
1. Uso Correcto de URIs
Cada página, información en una sección, archivo, cuando hablamos de REST, los
nombramos como recursos.
El recurso por lo tanto es la información a la que queremos acceder o que queremos
modificar o borrar, independientemente de su formato.
Las URL, Uniform Resource Locator , son un tipo de URI, Uniform Resource Identifier,
que además de permitir identificar de forma única el recurso, nos permite
localizarlo para poder acceder a él o compartir su ubicación.
Una URL se estructura de la siguiente forma:
{protocolo}://{dominio o hostname}[:puerto (opcional)]/{ruta del recurso}?{consulta de
filtrado}
Existen varias reglas básicas para ponerle nombre a la URI de un recurso:
• Los nombres de URI no deben implicar una acción, por lo tanto debe
evitarse usar verbos en ellos.
• Deben ser únicas, no debemos tener más de una URI para identificar un
mismo recurso.
• Deben ser independiente de formato.
• Deben mantener una jerarquía lógica.
• Los filtrados de información de un recurso no se hacen en la URI.
2. HTTP
Para desarrollar APIs REST los aspectos claves que hay que dominar y tener
claros son:
• Métodos HTTP
• Códigos de estado
• Aceptación de tipos de contenido
• Métodos.
Como hemos visto en el anterior nivel, a la hora de crear URIs no debemos poner
verbos que impliquen acción, aunque queramos manipular el recurso.
Para manipular los recursos, HTTP nos dota de los siguientes métodos con los cuales
debemos operar:
17
• GET: Para consultar y leer recursos
• POST: Para crear recursos
• PUT: Para editar recursos
• DELETE: Para eliminar recursos.
• PATCH: Para editar partes concretas de un recurso.
Por ejemplo, para un recurso de facturas.
GET /facturas Nos permite acceder al listado de facturas
POST /facturas Nos permite crear una factura nueva
GET /facturas/123 Nos permite acceder al detalle de una factura
PUT /facturas/123 Nos permite editar la factura, sustituyendo la totalidad de
la información anterior por la nueva.
DELETE /facturas/123 Nos permite eliminar la factura
PATCH /facturas/123 Nos permite modificar cierta información de la factura,
como el número o la fecha de la misma.
Uso de Códigos de estado

Cuando realizamos una operación, es vital saber si dicha operación se ha realizado
con éxito o en caso contrario, por qué ha fallado.
HTTP tiene un abanico muy amplio que cubre todas las posibles indicaciones que
vamos a tener que añadir en nuestras respuestas cuando las operaciones han ido
bien o mal.
Ver anexo I Anexo:Códigos de estado HTTP para identificar los estados de respuesta
HTTP e identificar el que debe ser utilizado en cada caso. (500, 200, 404, etc.)
18
Standard JSON
JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato

ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras
que para las máquinas es simple interpretarlo y generarlo. Está basado en un
subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd
Edition - Diciembre 1999. JSON es un formato de texto que es completamente
independiente del lenguaje, pero utiliza convenciones que son ampliamente
conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++,
C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que
JSON sea un lenguaje ideal para el intercambio de datos.
JSON está constituído por dos estructuras:
Una colección de pares de nombre/valor. En varios lenguajes esto es conocido como

un objeto, registro, estructura, diccionario, tabla hash, lista de claves o un arreglo
asociativo.
Una lista ordenada de valores. En la mayoría de los lenguajes, esto se implementa

como arreglos, vectores, listas o sequencias.
Estas son estructuras universales; virtualmente todos los lenguajes de programación

las soportan de una forma u otra. Es razonable que un formato de intercambio de
datos que es independiente del lenguaje de programación se base en estas
estructuras.
En JSON, se presentan de estas formas:
• JSON Nombre/Par de Valores
Para asignar a un nombre un valor debemos usar los dos puntos ':' este separador es
el equivalente al igual ('=') de cualquier lenguaje.
"Nombre" : "Geeky Theory"
• Objetos JSON
Los objetos JSON se identifican entre llaves, un objeto puede ser en nuestro caso
una fruta o una verdura.
{ "NombreFruta":"Manzana" , "Cantidad":20 }
19
• Arrays JSON
En un Json puedes incluir arrays, para ellos el contenido del array debe ir entre
corchetes []:
{
"Frutas": [
{ "NombreFruta":"Manzana" , "cantidad":10 },
{ "NombreFruta":"Pera" , "cantidad":20 },
{ "NombreFruta":"Naranja" , "cantidad":30 }
Valores Json
Los tipos de valores que podemos encontrar en Json son los siguientes:
• Un número (entero o float)

• Un string (entre comillas simples)
• Un booleano (true o false)
• Un array (entre corchetes [] )
• Un objeto (entre llaves {})
• Null
20
MariaDB
Dicho de forma sencilla, MariaDB es un remplazo de MySQL con más funcionalidades

y mejor rendimiento. MariaDB es un un fork de MySQL que nace bajo la licencia GPL.
Esto se debe a que Oracle compró MySQL y cambió el tipo de licencia por un privativo,
aunque mantuvieron MySQL Community Edition bajo licencia GPL. La compatibilidad
de MariaDB con MySQL es prácticamente total y por si fuese poco tenemos mejoras
de rendimiento y funcionalidad. MariaDB está diseñado para reemplazar a MySQL
directamente ya que mantiene las mismas órdenes, APIs y bibliotecas.
Lo primero que tiene que quedar totalmente claro es que al ser MariaDB compatible
con MySQL, la migración a MariaDB es simple y directa, no hay que adaptar el código
ni nada.
Ventajas de MariaDB.
• Nuevos motores de almacenamiento, para la mayoría de usuarios lo

interesante es Aria, que viene a reemplazar a MyISAM y también tenemos XtraDB
que reemplaza a InnoDB. Los nuevos motores de almacenaniemto son:
o Aria: Un motor de almacenamiento a prueba de fallos basado en
MyISAM.
o XtraDB: El reemplazo del motor InnoDB basado en el plug-in de
InnoDB.
o PBXT: Un motor de almacenamiento transaccional con una gran
cantidad de nuevas y bonitas características.
o FederatedX: El reemplazo del motor Federated.
• Mejoras de velocidad sobre todo en consultas complejas cuando se usa el

motor de almacenamiento Aria, ya que Aria cachea los datos de tablas temporales en
memoria, lo que supone un rendimiento frente al uso del disco duro (que es lo que
emplea MyISAM).
• Se añaden nuevas tablas de sistema (INFORMATION_SCHEMA) para
almacenar estadísticas que nos pueden ayudar a optimizar las bases de datos.
• El sistema para manejar las conexiones se ha mejorado, ya que implementa
el sistema pool-of-threads de MySQL 6.0 con el que podemos tener más de 200.000
conexiones a MariaDB.
• En general se han hecho muchas modificaciones para mejorar el rendimiento,
velocidad e incluso implementar características nuevas.
21
Uipath
Los robots construidos con UiPath ejecuta procesos con una precisión perfecta.
Pueden ejecutar tareas asistidas, ejecutándose automáticamente bajo el control y la
supervisión de un usuario, o sin ayuda, procesando trabajos de gran volumen
independientemente de la interacción humana.
Automatización Asistida
Este robot está diseñado para cooperar con los empleados en actividades
comerciales donde se requiere intervención humana. Reside en la estación de trabajo
del empleado, se activa cuando es necesario mediante un comando directo o eventos
de flujo de trabajo específicos, entregando una alta productividad y bajos tiempos de
operación en actividades administrativas, los servicios de asistencia y las actividades
de un call-center.
Automatización desatendida
Estos robots operan sin contacto humano, los Robots desatendidos son la clave para
maximizar los beneficios de costos y rendimiento para cualquier tipo de actividades
administrativas. Implementados por Orchestrator en entornos físicos o virtuales, se
activan automáticamente y se ejecutan de manera eficiente en modo por lotes. Es
posible acceder a estos robots de forma remota, con programación, administración
de carga de trabajo, informes, auditoría y monitoreo de forma segura y centralizada.
Para implementar estos robots se utilizará el entorno de desarrollo proporcionado por

UiPath Community Edition, denominado UiPath Studio.
UiPath Studio presenta una forma visual y declarativa de describir cómo automatizar
un proceso, los usuarios pueden usarlo de la misma manera que usan un diagrama
de Visio.
Al trabajar con la capa de presentación de otras aplicaciones, simplemente se debe

indicar en la pantalla qué operación necesita realizar.
UiPath entiende la UI en el nivel de control lógico y no depende de la posición de los

elementos en la pantalla. Esto hace que la automatización sea mucho más confiable
e independiente del tamaño y la resolución de la pantalla.
Los scripts de UiPath son visuales por naturaleza, uno puede observarlos y entender
de inmediato como indicarle al robot lo que se supone que deben hacer. Es muy fácil
mantenerlos y realizar pequeños cambios en el proceso.
22
Ilustración 8 - Flujos UIPath Studio – Fuente: https://www.uipath.com/automate/desktop-automation
23
Máquinas virtuales:
Como se mencionó anteriormente, cada robot debe correr en su propia estación de

trabajo (física o virtual), por este motivo optaremos por utilizar máquinas virtuales para
que en cada máquina virtual tengamos ejecutando una “Instancia” del robot RPA.
Una máquina virtual es un software que simula un sistema de computación y puede

ejecutar programas como si fuese una computadora real. Este software en un
principio fue definido como "un duplicado eficiente y aislado de una máquina física".
La acepción del término actualmente incluye a máquinas virtuales que no tienen
ninguna equivalencia directa con ningún hardware real.
Una característica esencial de las máquinas virtuales es que los procesos que
ejecutan están limitados por los recursos y abstracciones proporcionados por ellas.
Estos procesos no pueden escaparse de esta "computadora virtual".
Virtualización a nivel de sistema operativo
Esta técnica consiste en dividir una computadora en varios compartimentos

independientes de manera que en cada compartimento podamos instalar un servidor.
A estos compartimentos se los llama "entornos virtuales". Desde el punto de vista del
usuario, el sistema en su conjunto actúa como si realmente existiesen varios
servidores ejecutándose en varias máquinas distintas. Dos ejemplos son las zonas
de Solaris (Solaris Zones) y la técnica de Micro Partioning de AIX.
El software que utilizaremos para virtualizar las máquinas virtuales que utilizarán
nuestros robots RPA, será VirtualBox.
Oracle VM VirtualBox es un software de virtualización para arquitecturas x86/amd64,

creado originalmente por la empresa alemana innotek GmbH. Actualmente es
desarrollado por Oracle Corporation como parte de su familia de productos de
virtualización. Por medio de esta aplicación es posible instalar sistemas operativos
adicionales, conocidos como «sistemas invitados», dentro de otro sistema operativo
«anfitrión», cada uno con su propio ambiente virtual.
Entre los sistemas operativos soportados (en modo anfitrión) se encuentran

GNU/Linux, Mac OS X, OS/2 Warp , Microsoft Windows, y Solaris/OpenSolaris, y
dentro de ellos es posible virtualizar los sistemas operativos FreeBSD, GNU/Linux,
OpenBSD, OS/2 Warp, Windows, Solaris, MS-DOS y muchos otros.
La aplicación fue inicialmente ofrecida bajo una licencia de software privativo, pero en
enero de 2007, después de años de desarrollo, surgió VirtualBox OSE (Open Source
Edition) bajo la licencia GPL 2. Actualmente existe la versión privativa Oracle VM
VirtualBox, que es gratuita únicamente bajo uso personal o de evaluación, y está
sujeta a la licencia de "Uso Personal y de Evaluación VirtualBox" (VirtualBox Personal
Use and Evaluation License o PUEL) y la versión Open Source, VirtualBox OSE, que
es software libre, sujeta a la licencia GPL.
24
VirtualBox ofrece algunas funcionalidades interesantes, como la ejecución de
máquinas virtuales de forma remota, por medio del Remote Desktop Protocol (RDP),
soporte iSCSI, aunque estas opciones no están disponibles en la versión OSE.
En cuanto a la emulación de hardware, los discos duros de los sistemas invitados son
almacenados en los sistemas anfitriones como archivos individuales en un
contenedor llamado Virtual Disk Image, incompatible con los demás softwares de
virtualización.
Otra de las funciones que presenta es la de montar imágenes ISO como unidades
virtuales ópticas de CD o DVD, o como un disquete.
Tiene un paquete de controladores que permiten aceleración en 3D, pantalla

completa, hasta 4 placas PCI Ethernet (8 si se utiliza la línea de comandos para
configurarlas), integración con teclado y ratón.
Ilustración 9- Esquema Funcionamiento Máquinas Virtuales – Fuente:

https://www.xataka.com/especiales/maquinas-virtuales-que-son-como-funcionan-y-como-utilizarlas
25
GIT
A la hora de hacer copias de seguridad de nuestros documentos deberíamos

establecer ciertos criterios y medidas que nos ayuden a preservar un control sobre
qué guardamos, qué teníamos ya guardado y qué podremos guardar más adelante
(con vistas a prevenir falta de espacio o archivos redundantes).
Si evitar duplicados entre unos cuantos archivos y carpetas es así de complicado con
simples documentos, imágenes u otros ficheros, imaginemos cómo será llevar el
control de cientos, miles o millones de líneas de código.
Cada cambio, cada corrección o fallo detectado debería ser anotado para facilitarnos
el que al corregir cierto error conocido se genere algún otro, y por resto resultan muy
interesantes los distintos softwares de control de versiones que existen hoy en día.
Gracias a Internet donde es fácil encontrar cursos, cualquiera puede desarrollar una
aplicación web o móvil; que seguramente contendrá errores una vez se empiece a
distribuir o bien se le quieran ir añadiendo nuevas funcionalidades. El software de
control de versiones nos facilita esto, registrando una copia de cada versión que
finalicemos.
Pero no sólo para los desarrolladores individuales el control de versiones tiene su
utilidad. Si nos encontramos en un equipo de trabajo en el que las partes de cada
integrante están bien diferenciadas, conocer qué cambios ha hecho cada cual es
fundamental, tanto por los tiempos de espera que podríamos reducir al no saber si
otro grupo ha terminado su parte como por comprobar qué funciones se han ido
añadiendo en cada revisión.
Este registro también nos servirá de histórico, porque el hecho de que un proyecto se
divida en varias personas, supone que estas estarán añadiendo, guardando,
editando, etc… en varias partes de la aplicación. Con el control de versiones
podremos identificar quién ha escrito qué, dónde y cuándo.
¿Cómo funciona?
Primero deberemos implementar un servicio de control de versiones o suscribirnos a

un hosting que lo ofrezca (más adelante veremos algunos) y en ellos especificaremos
qué directorios de nuestro proyecto deberán ser seguidos por el control de versiones
(puede que no queramos rastrear todos los directorios por la inamovilidad de algún
dato en concreto).
Una vez hecho esto, deberemos designar a los colaboradores que tendrán acceso al
proyecto (deberán crearse una cuenta por lo general) y estableceremos los permisos
que queramos otorgarles.
Con estos parámetros configurados, los cambios se registrarán automáticamente,
pero éstos lo harán como una ‘colección’ de acciones llamada revisión;
asegurándonos así de acceder siempre a la versión más reciente de nuestro proyecto.
Si quisiéramos comparar dos revisiones (debido a que ha aparecido algún error, por
ejemplo) el servicio de control de versiones nos ofrecerá una comparativa
resaltándonos los datos o apartados modificados, código añadido, etc… de una a
otra, así como su autor, fecha, hora…
26
Al ya tener nuestro proyecto establecido, podremos controlar sus diferentes
versiones, accesos y demás. En caso de que queremos implementar un cambio
drástico (probar una nueva interfaz que no sabemos si se integrará bien con nuestros
componentes…) y no queremos que se cree la revisión de inmediato.
En estos casos podemos generar ramificaciones del proyecto principal (denominadas
‘branchs’), que no son más que una copia temporal en la que trabajaremos en paralelo
al proyecto para implementar o probar estos cambios. Si las pruebas son
satisfactorias podremos integrar esta rama de nuevo al hilo principal, sin embargo, en
caso resultar en catástrofe, podremos descartar los cambios sin asentar ninguna
nueva revisión al hilo principal.
Dependiendo de la configuración que hayamos establecidos, los sistemas de control
de versiones suelen tener cierta “inteligencia” para reconocer qué cambios deben
asentarse como revisiones, no obstante, en caso de no quererlo así o en caso que el
sistema sea incapaz de decidir qué cambios incluir en cada revisión, deberemos
solventar el conflicto manualmente.
Podríamos ilustrar todo esto de las ramas con la siguiente imagen:
Ilustración 10 - Ramas en Git – Fuente: http://course.readthedocs.io/en/latest/web/2016-spring/git-

html/branch.html
27
Un poco de Historia
Los sistemas de control de versiones no son recientes en absoluto, de hecho, ya han
pasado por varias generaciones:
• Primera Generación: Varias personas podían trabajar en el mismo archivo,

pero no simultáneamente ya que el archivo se bloqueaba para evitar estas múltiples
conexiones a la vez.
• Segunda Generación: Muchos de los sistemas de control de versiones que

nos ofrecen distintos hostings hoy día se encuentran en esta categoría. A diferencia
de la primera generación, varios usuarios pueden conectarse y trabajar de forma
simultánea en un mismo archivo, pero los cambios deberán combinarse en la revisión
actual antes de poder cerrarla para compararla con previas o posteriores.
o CVS (Concurrent Version System) es uno de los controladores de

versiones de esta generación. Permite interacciones cliente/servidor.
o SVN (o Apache Subversion in full) se podría entender como un
rediseño de CVS que pone fin a algunas de las limitaciones
establecidas.
• Tercera Generación: Destaca el DVCS (Distributed Version Control System) y su

posibilidad de separar y combinar operaciones de confirmación para generar las
diferentes revisiones, o el que diferentes ramas de un proyecto contengan a su
vez diferentes partes. Git es uno de sus ejemplos más reconocidos.
28
GitLab
En la actualidad existen diversos repositorios GIT para poder alojar nuestros

proyectos, es el caso Bitbucket, GitHub, GitLab, etc. A continuación, detallaremos las
características de nuestra elección, GitLab.
GitLab, a su vez, es un repositorio de gestión de proyectos dotado de interfaz web.

Como podemos deducir del nombre, está construido sobre Git, y básicamente nos
proporciona el código para generar un servidor y gestionar los clientes, sus opciones
y los servicios ofrecidos.
A través de GitLab, podemos gestionar grupos, personas y los permisos que

queremos que tengan los usuarios dentro de los grupos o proyectos a los que
pertenezcan. También nos permite llevar a cabo un seguimiento del estado actual y
del histórico de los proyectos pudiendo, así, ver todos los cambios y modificaciones
producidas en el tiempo de desarrollo, además de gráficos, otros datos de interés de
los proyectos y servicios que van más allá del control de versiones. Ejemplos de estos
servicios serían los comentarios de usuarios sobre un proyecto, herramientas de
planificación, issues (utilizados para reportar o avisar de errores), requests (para
facilitar a la comunidad de proyectos compartidos, se permite que la gente haga
peticiones de actualización con su código y que, si al propietario del proyecto le
parece adecuado, puedan aceptarse), etc.
Gitlab es software libre y gratuito, con una buena comunidad que lo va mejorando y
actualizando, y que crece y nos ofrece diversas funcionalidades interesantes que
listamos a continuación:
• Opción de autentificar contra servicios como LDAP; Un punto interesante, ya que

otros servicios similares a GitLab no nos ofrecían esta opción de autentificación.
• Distintos tipos de acceso y permisos (uso de roles y grupos); Restringiendo proyectos
a ciertos usuarios y permitiéndoles acceder a ciertos contenidos limitados o realizar
ciertas acciones concretas. Los usuarios pueden acceder al proyecto a través de la
web y por SSH (con intercambio de claves pública-privada).
• Seguimiento de incidencias y comentarios de un proyecto; A partir de la interfaz web,
los usuarios podrán comentar aspectos del proyecto que vean conveniente discutir.
Nos ofrece un servicio de tiqueting para hacer el seguimiento de incidencias u
objetivos del proyecto y se puede habilitar un wiki para la documentación que se
quiera hacer.
• Código del servidor fácilmente accesible remotamente; Trabajando con el servidor
proporcionado en nuestra máquina, podemos asegurar la conexión desde el exterior,
aislando así un punto de dependencia respecto a un servicio externo. Al tratarse de
un servicio de nuestro servidor, podemos activar filtros para limitar el acceso a un
rango de redes particular.
• Gestión de grupos y proyectos; Nos permite gestionar proyectos y grupos de usuarios
para realizar proyectos concretos, controlando los permisos de los integrantes y la
libertad que estos tienen. Estas funciones son prácticas para poder trabajar en equipo
con conjuntos de usuarios sin tener que definir restricciones individuales para cada
uno de ellos, permitiendo así mayor rapidez en la creación y definición de permisos y
una mayor facilidad, flexibilidad y rapidez si han de hacerse cambios.
• Capacidad para importar repositorios ya existentes; Puesto que GitLab es un sistema
relativamente nuevo y mucha gente ha trabajado ya en otros sistemas como GitHub
29
o en servidores externos al usar GitLab, nos permite crear repositorios a partir de
otros ya creados con anterioridad.
• Cómoda interfaz web; Práctica interfaz web para interaccionar con GitLab que nos
permite trabajar más intuitivamente y que nos da un feedback más elevado que el
terminal además de simplificar el uso del sistema y la revisión de proyectos.
• Copias ed seguridad; Al tener el servicio en el servidor, a persar de trabajar con copias
locales en el ordenador en el que nos hallamos, si perdiésemos alguna parte de
nuestro proyecto, disponemos siempre de copias del sistema que no hayan sido
comprometidas gracias a funcionar usando Git.
• Historial de modificaciones del proyecto; Especialmente práctico en trabajos en grupo
debido a que, cuando alguien hace alguna modificación, nos permite verla clara e
intuitivamente ahorrándonos largas explicaciones o investigación sobre el código.
Además, al poder trabajar con un servidor propio, podemos gestionar el espacio

cedido a los usuarios (como, por ejemplo, poner un control de cuotas), regular el
acceso al servicio y activar/desactivar servicios según interese.
Para poder instalar y utilizar Gitlab, necesitaremos tener en nuestro servidor ciertos
programas y librerías. Sin entrar demasiado en detalles, comentamos sobre qué
tecnologías trabaja:
• Python.
• Ruby.
• Git.
• Mysql (mysqlserver mysqlclient).
• Nginx.
• El propio código de GitLab.
• Llibrerías externas.
• SecureShell.
Además, nos hará falta el servidor en el que queremos instalar el servicio y la conexión
a través de la cual los usuarios puedan acceder a estos servicios, ya que, al tratarse
de un servidor de repositorios, lo que nos interesará será el acceso remoto.
30
III PRODUCTO FINAL
III.1 Presentación del Problema
En la empresa 2080 S.A. existen varias actividades administrativas que son

realizadas por los ejecutivos pertenecientes a diversos servicios dentro de la
organización.
Después de un análisis efectuado entre todas las actividades realizadas por los
ejecutivos, se pudo determinar la actividad que más demanda tiempo dentro del
universo de actividades es la de “Agendamiento de Equipos”.
A continuación, se detallan los conceptos que nos ayudarán a definir los criterios
utilizados en este análisis para determinar la actividad que demanda más tiempo
dentro del equipo de ejecutivos.
• TMO: Tiempo medio de operación, consiste en el tiempo que demora un

ejecutivo en ejecutar una tarea administrativa, este tiempo es medido en minutos.
• SLA: Service Level Agreement, como concepto es un acuerdo entre cliente y

proveedor para acordar un nivel de calidad asociado al servicio acordado, puede ser
tiempo, calidad, dinero, etc.
Para este análisis el SLA corresponde una cantidad de tiempo en que el
requerimiento debe estar ejecutado satisfactoriamente.
• Cantidad: Son el número de actividades que son solicitadas dentro de un

rango de tiempo. Para este estudio la muestra que fue tomada corresponde a las
actividades solicitadas desde el 01/01/2017 al 31/10/2017.
Teniendo claro estos conceptos, definiremos con Z al indicador que mostrará el

tiempo que demanda cada actividad en el equipo.
Este indicador podrá ser obtenido bajo la siguiente formula:
Z = TMO * Cantidad
Con esta fórmula, las actividades que tengan mayor Z, son las que toman más tiempo
dentro de la operación de los ejecutivos del equipo de administración ventas.
31
Se adjunta listado de actividades con su respectivo TMO (en minutos) y Q de
actividades ingresadas en el periodo de enero-octubre del año 2017.
Q
id Tipo Actividad TMO(minutos) actividades
528 Solicitud Portabilidad Web - Remedy 30 20
527 Solictud Venta Web - Remedy 15 574
382 FACTIBILIDAD PORTABILIDAD MOVIL EMPRESAS 10 28.862
398 Venta Contingencia 8,6 430
529 Contacto telefónico AM/Cliente 8 62
400 Ingreso Preventa (GRC/Descuentos/autokit) 7,6 27.342
408 Rechazo Venta (Análisis, Solicitud) - Salesforce/Casilla 6,4 2.774
406 Consultas varias (status peticion-plan-SF) 6 2.664
402 AGENDAMIENTO EQUIPOS 5,8 79.902
405 Solicitudes Back Masivo (Bajas, Mantenedor) - Casilla 5,8 5.656
Seguimientos (Preventa/Creación Plan/Aprobaciones Desc/Grc) - 12.814
403 Salesforce 5,6
404 Notificaciones a AM/CLIENTE 5,4 7.134
410 Gestor Documental - Salesforce/Casilla 5,4 8.146
360 VALIDACION PORTABILIDAD MOVIL EMPRESAS 3,13 18.130
361 PREPARACION PORTABILIDAD MOVIL EMPRESAS 3,13 8.122
362 Seguimiento Despachos Control Salida 1,88 5.172
134 Cambio de Plan 1,74 106.750
357 Visado ventas SF 1,15 67.154
Tabla 2 - TMO Actividades
32
Con la tabla anterior procedemos a aplicar la fórmula mencionada anteriormente para
obtener el TOP 5 de actividades con mayor Z.
Z por Tipo de Actividad
Agendamiento Equipos
77.227
185.745 FACTIBILIDAD PORTABILIDAD

463.432 MOVIL EMPRESAS
Ingreso Preventa
(GRC/Descuentos/autokit)
207.799 Cambio de Plan
Visado ventas SF
288.620
Ilustración 11 - Top 5 Actividades – Fuente Elaboración Propia
Con estos antecedentes, analizaremos cómo es ejecutada la actividad de tipo

“Agendamiento Equipo”, que sistemas son los necesarios para su ejecución, el origen
y formato de los datos que deben ser procesados, etc.
Teniendo todos estos antecedentes podremos determinar el esfuerzo que tomará el

poder automatizar este tipo de actividad.
33
¿En qué consiste un Agendamiento de Equipo?
Vamos a partir por definir que es un plan empresas, este tipo de planes lo poseen las
empresas y corporaciones clientes de Telefónica Chile. Este tipo de plan consiste en
un conjunto de líneas y equipos móviles que están a nombre de cada empresa.
Cuando una empresa adquiere una nueva línea o cambia el equipo de una línea que
se encuentra activa, el equipo debe ser despachado donde lo indique el cliente.
Es por eso, que se debe ingresar una solicitud de agendamiento por cada equipo que
adquiere la empresa, para así validar diversos datos como: stock del o los modelos,
valores según plan, servicios de telefonía y datos para cada equipo, etc. Como es de
suponer, las grandes empresas como Cencosud, Falabella, Ultramar, etc. realizan
solicitudes de grandes volúmenes de equipos, por lo que un ejecutivo puede tomarse
más de un día agendando sólo una solicitud de equipos en sistema.
Actualmente, estas solicitudes deben ser ingresadas por los ejecutivos del equipo de
administración ventas, en un sistema web de Telefónica llamado Salesforce, por lo
que debemos darle a nuestro robot RPA las instrucciones para que tenga la capacidad
de poder manipular este sistema para lograr el ingreso de solicitudes de forma
autónoma.
El que Salesforce sea un sistema Web, nos proporciona un gran escenario para que
actúe nuestro robot, ya que UIPath nos proporciona detección de controles dentro del
formulario, reconocimiento de texto mediante OCR, captura de eventos web, etc.
Origen y Formato de Datos
Al robot se le debe informar de alguna forma los datos que debe ingresar en
Salesforce, que modelo seleccionar, que plan asignar al equipo, donde despacharlo,
etc.
Para esto, programaremos nuestro robot con el objetivo de que pueda leer un archivo
Excel en un formato determinado, el cual será el que contenga todos los datos de
cada equipo que debe ser agendado dentro de la solicitud. Este archivo debe ser
llenado por el ejecutivo de Administración Ventas, para posteriormente realizar el
ingreso de una actividad en el sistema web adjuntando el archivo Excel para delegar
su ejecución al robot.
A continuación, se adjunta una tabla de equivalencia entre el documento Excel

que llenará el ejecutivo, para que el robot los extraiga y los ingrese en el sistema Web
según corresponda. Cada fila del archivo Excel corresponde a una actividad que debe
realizar el robot.
34
Campo Formulario Campo Excel Valor Ejemplo
WEB
Código de Cliente Código de Cliente 31109862
Solicitud Solicitud 000234069
Id de Modelo Id de modelo 3778
Cantidad de equipos Cantidad de Equipos 2
Plan Código de Plan ZVA
Tipo de Contrato Tipo de Contrato 02 - SUMINISTRO SIN
EQUIPO
Código de descuento de modelo Código de Descuento DM-091020
Servicio Catálogo de Servicio1 XXX - NO REQUIERE
SERVIO SEGUN OC
Accion Acción Activar
Contacto Contacto Bárbara Eshmann
Teléfono de contacto Teléfono de Contacto 227202413
Dirección Dirección AV. GLADYS MARIN
5830
Comuna Comuna ESTACION CENTRAL
Modalidad de Venta Modalidad de Venta 1 - CONTADO
SGP Código SGP 578543241405
Número Número a Portar 979476324
Tabla 3 - Tabla Equivalencia Excel - Web
Ilustración 12 - Formulario Agendamiento Venta – Fuente: https://telefonicab2b.force.com/portalpartner
35
Ilustración 13 - Formulario Agendamiento Portabilidad - Fuente: https://telefonicab2b.force.com/portalpartner
36
III.2 Desarrollo del Problema
Cabe destacar que el diseño de nuestra plataforma se ideó de una manera escalable,
para que por el momento cubra el agendamiento de equipos, pero a futuro puedan
ser agregadas más actividades con el menor esfuerzo posible.
El robot que implementaremos tendrá la capacidad de realizar agendamientos de

equipos cuando exista una nueva venta o una nueva portabilidad.
A continuación, detallaremos todos los elementos que utilizamos en el diseño, los

flujos, diagramas, prototipos, etc.
Diagrama BPMN
Ilustración 14 - Diagrama BPMN Agendamiento Equipos – Fuente Elaboración Propia
37
Modelo de Datos
El framework Laravel tiene ciertas convenciones que debemos seguir para poder
utilizarlo, una de estas convenciones es el nombre de las tablas, siempre deben ser
el plural del nombre del Modelo que utilizaremos. Por ejemplo, para la tabla empresas
su modelo en Laravel será Empresa. Es por eso que la tabla que almacena las
actividades se llama actividads, para bajo la convención de Laravel su modelo se
llame Actividad.
Ilustración 15 - Modelo de Datos – Fuente Elaboración Propia
38
Diccionario de datos
Tabla: actividads
Nombre Descripción Tipo de Dato Obligatorio PK
Identificador unico del registro en la
id Integer X SI
tabla
Estado en el que se encuentra la
estado_id Integer X
actividad
Observaciones ingresadas al
descripcion Text X
momento de crear la actividad
user_id Usuario asociado a la actividad Integer X
created Fecha de Creación del registro Timestamp X
Fecha de última actualización del
modified Timestamp
registro
Fecha en que el Robot inicia la
fecha_proceso Timestamp
ejecución de la actividad
Fecha tope de término de actividad,
fecha_termino dada por el SLA del tipo de la Timestamp
actividad
Fecha en que el robot termina la
fecha_cierre Timestamp
ejecución de la actividad
empresa_id Empresa asociada a la actividad Integer X
tipoactividad_id Tipo al que pertenece la actividad Integer X
Tabla: actualizacions
Identificador único del registro en la
id Integer X SI
tabla
actividad_id Actividad asociada a la actualización Integer X
Estado de la actividad, ingresado en
estado_id Integer
la actualización
Usuario que realiza el ingreso de la
user_id Integer X
actualización
Observaciones ingresadas al
descripcion Text X
momento de crear la actualización
modified Timestamp
registro
39
Tabla: adjuntos
id Integer X SI
tabla
tipoadjunto_id Tipo al que pertenece el adjunto Integer
Variable
path Ubicación en el servidor del adjunto characters X
(200)
Variable
Nombre con el que fue subido el
nombre_real characters X
adjuntos
(100)
Nombre temporal con el que fue Variable
nombre_tmp guardado el adjunto en el servidor characters X
(hash) (100)
modified Timestamp
registro
actividad_id Actividad asociada al adjunto Integer X
Tabla: empresas
id Integer X SI
tabla
Variable
rut Rut de la Empresa X
characters (11)
Variable
razon_social Nombre de la Empresa characters X
(100)
modified Timestamp
registro
Estado en el que se encuentra la
estado_id Integer X
empresa
Segmento al que pertenece la
segmento_id Integer X
empresa
Tabla: empresas_users
id Integer X SI
tabla
empresa_id Empresa asociada al registro Integer X
user_id Usuario asociado al registro Integer X
created Fecha de creación del Registro Timestamp X
40
Tabla: equipos
id Integer X SI
tabla
Variable
descripcion Nombre del equipo characters X
(100)
modified Timestamp
registro
Tabla: estados
id Integer X SI
tabla
Variable
descripcion Nombre del estado characters X
(100)
modified Timestamp
registro
Tabla: perfils
id Integer X SI
tabla
Variable
descripcion Nombre del perfil characters X
(100)
modified Timestamp
registro
Tabla: segmentos
id Integer X SI
tabla
Variable
Nombre del Segmento de la
descripcion characters X
empresa
(100)
modified Timestamp
registro
41
Tabla: tipoactividads
id Integer X SI
tabla
Variable
descripcion Nombre del Tipo de actividad characters X
(100)
Horas Hábiles que puede demorar
sla Integer X
un tipo de actividad
modified Timestamp
registro
Tabla: tipoadjuntos
id Integer X SI
tabla
Variable
descripcion Nombre del Tipo de adjunto characters X
(100)
modified Timestamp
registro
Extensiones de los tipos de archivo Variable
extensiones que son aceptados por el tipo de characters
adjunto (100)
42
Tabla: users
id Integer X SI
tabla
Variable characters
nombre Nombre del Usuario X
(100)
Variable characters
apellido Apellido del Usuario X
(100)
Variable characters
rut Rut del usuario X
(11)
Nombre de usuario para ingresar al Variable characters
username X
sistema (50)
Contraseña del usuario para ingresar Variable characters
password X
al sistema (100)
Estado en el que se encuentra el
estado_id Integer X
usuario
perfil_id Perfil al que pertenece el usuario Integer X
equipo_id Equipo al que pertenece el usuario Integer X
modified Timestamp
registro
Variable characters
email Email del Usuario X
(100)
Tabla 4 - Diccionario de Datos
43
Diagramas UML
Diagramas de casos de Uso
Ilustración 16 - Casos de Uso Sistema Web – Fuente Elaboración Propia
44
Ilustración 17 - Casos de uso - API Rest – Fuente Elaboración Propia
45
Casos de Uso
Nombre Caso de Uso: Login

Código Caso de Uso: CAS-001
Autor: Marco Soruco H.
Fecha: 15-12-2017
Descripción: Permite validar mediante email y contraseña, el ingreso del usuario
en sistema.
Actores: Usuario / Administrador
Precondiciones:
Flujo Normal: 1.- El usuario Selecciona la opción Login

2.- El usuario ingresa su correo electrónico en el campo Email
3.- El usuario ingresa su contraseña en el campo Password
4.- El usuario selecciona el botón Ingresar
5.- El sistema comprueba la validez de los datos
6.- El usuario ingresa a su bandeja de actividades
Flujo Alternativo: 5-A.- Los datos son inválidos el usuario es direccionado a la página
de login nuevamente
PostCondiciones: La sesión del usuario es creada en sistema.
Tabla 5 - Caso de Uso Login
46
Nombre Caso de Uso: Ingresar Actividad
Código Caso de Uso: CAS - 002
Fecha: 15-12-2017
Descripción: Permite ingresar una actividad en sistema.
Actores: Usuario
Precondiciones: 1.-Usuario debe estar registrado en sistema
Flujo Normal: 1.- El usuario selecciona sobre la opción “Ingresar actividad”

2.- El usuario ingresa el rut de la empresa dueña de la actividad
3.- Al perder el foco del campo rut, el sistema busca si la empresa
está asociada a la cartera del usuario
4.- Se carga automáticamente la Razón social en el formulario
5.- El usuario completa el formulario
6.- El usuario pulsa el botón Ingresar Actividad
7.- El sistema registra la actividad y la deja en estado Ingresado
Flujo Alternativo: 3-A.- La empresa no se encuentra en la cartera del usuario
3-B .- Se muestra un mensaje de alerta y se borra el rut
PostCondiciones: La actividad es guardada en sistema

La actividad queda asociada al usuario que la ingresó
Tabla 6 - Caso de Uso Ingresar Actividad
47
Nombre Caso de Uso: Obtiene Empresa
Fecha: 15-12-2017
Descripción: Obtiene todos los datos de la empresa en base al rut ingresado
Actores: Usuario
Precondiciones: El usuario se encuentra en el formulario de ingreso de actividad

El usuario debe estar registrado en sistema
Flujo Normal: 1.- El usuario ingresa el rut de la empresa

2.- El sistema busca el rut y obtiene los datos
3.- Los datos de la empresa encontrada son devueltos en forma de
JSON.
Flujo Alternativo: 2-A.- La empresa no es encontrada, se responde un json con
mensaje de información.
PostCondiciones: Datos de empresa encontrados
Tabla 7 - Caso de uso obtiene empresa
48
Nombre Caso de Uso: Actualizar Actividad
Fecha: 15-12-2017
Descripción: Permite registrar una actualización de sistema al momento de
actualizar una actividad.
Actores: Usuario/Robot
Precondiciones: El usuario debe estar logueado en sistema

El usuario se debe encontrar en su bandeja de actividades
Flujo Normal: 1.- El usuario selecciona la opción Actualizar de una actividad

dentro de la lista
2.- Se despliega el formulario de ingreso de actualización
3.-El usuario completa el formulario
4- Se ingresa un registro en la tabla de actualizaciones asociado a la
actividad seleccionada.
5.- Se despliega un mensaje de confirmación del ingreso de
actualización
6.- El usuario es re direccionado a su bandeja de actividades
Flujo Alternativo: 4.A.- Si fue modificado el estado, se actualiza la actividad con el

nuevo estado ingresado.
PostCondiciones: La actualización fue registrada

El estado de la actividad fue actualizado
Tabla 8 - Caso de Uso Actualizar Actividad
49
Nombre Caso de Uso: Ver Actividad
Fecha: 15-12-2017
Descripción: Obtiene el detalle de una actividad en específico
Actores: Usuario/Robot

El usuario se debe encontrar en su bandeja de actividades
Flujo Normal: 1.- El usuario selecciona la opción Ver, de una actividad dentro del
listado de actividades.
2.- El sistema busca los datos de la actividad
3.-Se muestra una pantalla no editable con todos los datos de la
actividad.
4.- Las actualizaciones asociadas a la actividad se muestran en
una tabla, posterior a los datos de la actividad.
Flujo Alternativo: 2-A.- La actividad no existe, se muestra un mensaje de alerta.
PostCondiciones: Datos de actividad desplegados.
Tabla 9 - Caso de Uso Ver Actividad
50
Nombre Caso de Uso: Buscar Actividades
Fecha: 15-12-2017
Descripción: Permite ubicar una o más actividades seleccionando uno o más
filtros de búsqueda.
Actores: Usuario
Flujo Normal: 1.- El usuario selecciona la opción Buscar Actividades en el

menú principal
2.- El usuario selecciona y completa uno más filtros de los
siguientes filtros de búsqueda:
• Fecha Creación
• Estado
• Usuario
• Fecha término
• Fecha Cierre
• Id Actividad
• Tipo de actividad
3.- El usuario pulsa sobre el botón buscar
4.-El sistema obtiene las actividades según el o los filtros de
búsqueda ingresados.
5.- Se despliega una tabla con el listado de las actividades que
coincidieron con los filtros ingresados.
6.- Cada registro de la tabla deberá tener las opciones de Ver y
Actualizar
.
Flujo Alternativo: 3-A.- Si ninguna actividad coincide con los filtros de búsqueda
ingresados de muestra un mensaje de información.
PostCondiciones: Actividades encontradas y desplegadas.
Tabla 10 - Caso de Uso Buscar Actividades
51
Nombre Caso de Uso: Bandeja Actividades
Fecha: 15-12-2017
Descripción: Lista las actividades que se encuentran pendientes de gestionar y
se encuentran asociadas al usuario registrado
Actores: Usuario
Flujo Normal: 1.- El usuario selecciona la opción “Mi bandeja de actividades” o

realiza login en sistema.
2.- El sistema obtiene las actividades asociadas al usuario y las
ordena según su fecha de término más próximo.
3.- Se despliega una tabla con el listado de las actividades
pendientes y del usuario
4.- Cada registro de la tabla deberá tener las opciones de Ver y
Actualizar
Flujo Alternativo: 2-A.- El usuario no tiene actividades, se despliega una tabla en

blanco.
PostCondiciones: Listado de actividades pendientes desplegado.
Tabla 11 - Caso de Uso Bandeja de Actividades
52
Nombre Caso de Uso: Selecciona Actividad a Ejecutar
Fecha: 15-12-2017
Descripción: Obtiene la actividad más crítica que se encuentra pendiente para
que la pueda ejecutar el robot.
Actores: Robot
Precondiciones: Deben existir actividades pendientes de ejecución
Flujo Normal: 1.- El robot mediante un request solicita la actividad enviando

como parámetro el tipo de actividad que desee ejecutar
2. El sistema busca la próxima actividad a ejecutar.
3.- El sistema responde los datos de la actividad en formato JSON
Flujo Alternativo: 2-A.- Si no existen actividades pendientes, envía un mensaje en
JSON
PostCondiciones: Datos de actividad enviados
Tabla 12 - Caso de Uso Selecciona actividad a ejecutar
53
Nombre Caso de Uso: Crear usuario
Fecha: 15-12-2017
Descripción: Permite dar de alta un usuario del sistema
Actores: Admin
Precondiciones: Usuario debe estar logueado en sistema

Usuario debe tener perfil de administrador
Flujo Normal: 1.- El usuario selecciona la opción “Crear usuario” dentro del meno
principal.
2.- Se despliega un formulario con los datos del usuario
3.- Al perder el foco del campo email se ejecuta un Ajax para validar
si correo de usuario ya existe
4.- El usuario completa el formulario
5.- Usuario pulsa el botón Guardar
6.- El sistema ingresa el usuario en sistema
Flujo Alternativo: 3-A.- Si correo existe se debe desplegar un mensaje de alerta en el
formualrio
PostCondiciones: Usuario registrado en sistema
Tabla 13 - Caso de Uso Crear Usuario
54
Nombre Caso de Uso: Cambiar contraseña
Fecha: 15-12-2017
Descripción: Permite modificar la contraseña de ingreso al sistema para un
usuario determinado.
Actores: Admin/Usuario
Precondiciones: Usuario debe estar logueado en sistema
Flujo Normal: 1.- El usuario selecciona la opción “Cambiar contraseña” del menú
principal en caso de ser administrador debe seleccionar la opción
dentro del listado de usuarios.
2.A Si usuario es administrador debe ingresar la nueva contraseña
en el campo contraseña y conformación
2.B Si usuario es normal, debe completar el campo contraseña
actual y los campos nueva contraseña y confirmación.
3.- usuario pulsa sobre el botón actualizar
4.- El sistema actualiza la contraseña del usuario
Flujo Alternativo: 2 –A Si contraseña actual no coincide se despliega un mensaje de

alerta
2 B Si contraseña y confirmación no coinciden, se despliega un
mensaje de alerta
PostCondiciones: Contraseña Actualizada
Tabla 14 - Caso de Uso Cambiar Contraseña
55
Diagrama de estados
Ilustración 18 - Diagrama de Estados – Fuente Elaboración Propia
56
Diagrama de Arquitectura Física
Ilustración 19 - Arquitectura Servidores - Fuente Elaboración Propia
57
Mockups
Login
Ilustración 20 - Pantalla de Ingreso - Fuente Elaboración Propia
Ingreso de Actividad
Ilustración 21 Ingreso de Actividad – Fuente Elaboración Propia
58
Bandeja de Actividades
Ilustración 22 - Bandeja de Actividades de Usuario - Fuente Elaboración Propia
Actualizar Actividad
Ilustración 23 - Actualización de Actividad – Fuente Elaboración Propia
59
Bitácora Actualizaciones por Actividad
Ilustración 24 - Detalle actividad - Fuente Elaboración Propia
Dashboard
Ilustración 25 Dashboard Actividades - Fuente Elaboración Propia
60
IV ASPECTOS COMPLEMENTARIOS
BIBLIOGRAFÍA
Scrum:
https://proyectosagiles.org/que-es-scrum/
https://www.sinnaps.com/blog-gestion-proyectos/metodologia-scrum
Laravel:
https://ajgallego.gitbooks.io/laravel-5/content/introduccion.html
Angular
http://blog.enriqueoriol.com/2016/06/introduccion-a-angular-2-parte-i-componente.html
https://angular.io/guide/architecture
Rest:
http://asiermarques.com/2013/conceptos-sobre-apis-rest/
https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional
Json:
https://www.json.org/json-es.html
https://geekytheory.com/json-i-que-es-y-para-que-sirve-json/
MariaDB
https://mariadb.com/kb/es/what-is-mariadb-51/
http://www.vozidea.com/que-es-mariadb-y-ventajas-frente-mysql
61
UiPath
https://www.uipath.com/community
https://www.uipath.com/robot
Máquinas Virtuales
https://www.xataka.com/especiales/maquinas-virtuales-que-son-como-funcionan-y-
como-utilizarlas
GIT
https://barradevblog.wordpress.com/2013/01/21/que-es-gitgithub/
GitLab
https://about.gitlab.com/
62
ANEXOS
I. Anexo:Códigos de estado HTTP
1xx: Respuestas informativas
Petición recibida, continuando proceso. Esta respuesta significa que el servidor ha

recibido los encabezados de la petición, y que el cliente debería proceder a enviar el
cuerpo de la misma (en el caso de peticiones para las cuales el cuerpo necesita ser
enviado; por ejemplo, una petición Hypertext Transfer Protocol). Si el cuerpo de la
petición es largo, es ineficiente enviarlo a un servidor, cuando la petición ha sido ya
rechazada, debido a encabezados inapropiados. Para hacer que un servidor
chequee si la petición podría ser aceptada basada únicamente en los encabezados
de la petición, el cliente debe enviar Expect: 100-continue como un encabezado en
su petición inicial (vea Plantilla:Web-RFC: Expect header) y verificar si un código de
estado 100 Continue es recibido en respuesta, antes de continuar (o recibir 417
Expectation Failed y no continuar).
100 - Continue
El navegador puede continuar realizando su petición (se utiliza para indicar

que la primera parte de la petición del navegador se ha recibido correctamente).
101 - Switching Protocols
El servidor acepta el cambio de protocolo propuesto por el navegador (puede

ser por ejemplo un cambio de HTTP 1.0 a HTTP 1.1).
102 - Processing (WebDAV - RFC 2518)
El servidor está procesando la petición del navegador, pero todavía no ha

terminado (esto evita que el navegador piense que la petición se ha perdido cuando
no recibe ninguna respuesta).
103 - Checkpoint
Se va a reanudar una petición POST o PUT que fue abortada previamente.
2xx: Peticiones correctas
Esta clase de código de estado indica que la petición fue recibida correctamente,
entendida y aceptada.
200 - OK
Respuesta estándar para peticiones correctas.
63
201 - Created
La petición ha sido completada y ha resultado en la creación de un nuevo

recurso.
202 - Accepted
La petición ha sido aceptada para procesamiento, pero este no ha sido

completado. La petición eventualmente pudiere no ser satisfecha, ya que podría ser
no permitida o prohibida cuando el procesamiento tenga lugar.
203 - Non-Authoritative Information (desde HTTP/1.1)
La petición se ha completado con éxito, pero su contenido no se ha obtenido

de la fuente originalmente solicitada sino de otro servidor.
204 - No Content
La petición se ha completado con éxito pero su respuesta no tiene ningún

contenido (la respuesta sí que puede incluir información en sus cabeceras HTTP).
205 - Reset Content
La petición se ha completado con éxito, pero su respuesta no tiene

contenidos y además, el navegador tiene que inicializar la página desde la que se
realizó la petición (este código es útil por ejemplo para páginas con formularios cuyo
contenido debe borrarse después de que el usuario lo envíe).
206 - Partial Content
La petición servirá parcialmente el contenido solicitado. Esta característica es

utilizada por herramientas de descarga como wget para continuar la transferencia de
descargas anteriormente interrumpidas, o para dividir una descarga y procesar las
partes simultáneamente.
207 - Multi-Status (Multi-Status, WebDAV)
El cuerpo del mensaje que sigue es un mensaje XML y puede contener algún
número de códigos de respuesta separados, dependiendo de cuántas sub-
peticiones sean hechas.
208 - Already Reported (WebDAV)
El listado de elementos DAV ya se notificó previamente, por lo que no se van

a volver a listar.
64
3xx: Redirecciones
El cliente tiene que tomar una acción adicional para completar la petición.
Esta clase de código de estado indica que una acción subsecuente necesita
efectuarse por el agente de usuario para completar la petición. La acción requerida
puede ser llevada a cabo por el agente de usuario sin interacción con el usuario si y
solo si el método utilizado en la segunda petición es GET o HEAD. El agente de
usuario no debe redirigir automáticamente una petición más de 5 veces, dado que
tal funcionamiento indica usualmente un Bucle infinito.
300 - Multiple Choices
Indica opciones múltiples para el URI que el cliente podría seguir. Esto
podría ser utilizado, por ejemplo, para presentar distintas opciones de formato para
video, listar archivos con distintas extensiones o word sense disambiguation.
301 - Moved Permanently
Esta y todas las peticiones futuras deberían ser dirigidas a la URI dada.
302 - Found
Este es el código de redirección más popular, pero también un ejemplo de

las prácticas de la industria contradiciendo el estándar. La especificación HTTP/1.0
(RFC 1945) requería que el cliente realizara una redirección temporal (la frase
descriptiva original fue "Moved Temporarily"), pero los navegadores populares lo
implementaron como 303 See Other. Por tanto, HTTP/1.1 añadió códigos de estado
303 y 307 para eliminar la ambigüedad entre ambos comportamientos. Sin embargo,
la mayoría de aplicaciones web y bibliotecas de desarrollo aún utilizan el código de
respuesta 302 como si fuera el 303.
303 - See Other (desde HTTP/1.1)
La respuesta a la petición puede ser encontrada bajo otra URI utilizando el

método GET.
304 - Not Modified
Indica que la petición a la URL no ha sido modificada desde que fue

requerida por última vez. Típicamente, el cliente HTTP provee un encabezado como
If-Modified-Since para indicar una fecha y hora contra la cual el servidor pueda
comparar. El uso de este encabezado ahorra ancho de banda y reprocesamiento
tanto del servidor como del cliente.
65
305 - Use Proxy (desde HTTP/1.1)
Muchos clientes HTTP (como Mozilla3 e Internet Explorer) no se apegan al

estándar al procesar respuestas con este código, principalmente por motivos de
seguridad.
306 - Switch Proxy
Este código se utilizaba en las versiones antiguas de HTTP pero ya no se

usa (aunque está reservado para usos futuros).2
307 - Temporary Redirect (desde HTTP/1.1)
Se trata de una redirección que debería haber sido hecha con otra URI, sin
embargo, aún puede ser procesada con la URI proporcionada. En contraste con el
código 303, el método de la petición no debería ser cambiado cuando el cliente
repita la solicitud. Por ejemplo, una solicitud POST tiene que ser repetida utilizando
otra petición POST.
308 - Permanent Redirect
El recurso solicitado por el navegador se encuentra en otro lugar y este cambio es

permanente. A diferencia del código 301, no se permite cambiar el método HTTP
para la nueva petición (así, por ejemplo, si envías un formulario a un recurso que ha
cambiado de lugar, todo seguirá funcionando bien).
66
4xx Errores del cliente
La solicitud contiene sintaxis incorrecta o no puede procesarse.
La intención de la clase de códigos de respuesta 4xx es para casos en los

cuales el cliente parece haber errado la petición. Excepto cuando se responde a una
petición HEAD, el servidor debe incluir una entidad que contenga una explicación a
la situación de error, y si es una condición temporal o permanente. Estos códigos de
estado son aplicables a cualquier método de solicitud (como GET o POST). Los
agentes de usuario deben desplegar cualquier entidad al usuario. Estos son
típicamente los códigos de respuesta de error más comúnmente encontrados.
400 - Bad Request
La solicitud contiene sintaxis errónea y no debería repetirse.
401 - Unauthorized
Similar al 403 Forbidden, pero específicamente para su uso cuando la

autentificación es posible, pero ha fallado o aún no ha sido provista. Vea
autenticación HTTP básica y Digest access authentication.
402 - Payment Required
La intención original era que este código pudiese ser usado como parte de
alguna forma o esquema de Dinero electrónico o micropagos, pero eso no sucedió,
y este código nunca se utilizó.
403 - Forbidden
La solicitud fue legal, pero el servidor rehúsa responderla dado que el cliente
no tiene los privilegios para hacerla. En contraste a una respuesta 401 No
autorizado, la autenticación no haría la diferencia.
404 - Not Found
Recurso no encontrado. Se utiliza cuando el servidor web no encuentra la

página o recurso solicitado.
405 - Method Not Allowed
Una petición fue hecha a una URI utilizando un método de solicitud no soportado
por dicha URI; por ejemplo, cuando se utiliza GET en un formulario que requiere que
los datos sean presentados vía POST, o utilizando PUT en un recurso de solo
lectura.
67
406 - Not Acceptable
El servidor no es capaz de devolver los datos en ninguno de los formatos

aceptados por el cliente, indicados por éste en la cabecera "Accept" de la petición.
407 - Proxy Authentication Required
408 - Request Timeout
El cliente falló al continuar la petición - excepto durante la ejecución de

videos Adobe Flash cuando solo significa que el usuario cerró la ventana de video o
se movió a otro. ref
409 - Conflict
Indica que la solicitud no pudo ser procesada debido a un conflicto con el

estado actual del recurso que esta identifica.
410 - Gone
Indica que el recurso solicitado ya no está disponible y no lo estará de nuevo.

Debería ser utilizado cuando un recurso ha sido quitado de forma permanente.
Si un cliente recibe este código no debería volver a solicitar el recurso en el

futuro. Por ejemplo, un buscador lo eliminará de sus índices y lo hará más
rápidamente que utilizando un código 404.
411 - Length Required
El servidor rechaza la petición del navegador porque no incluye la cabecera

Content-Length adecuada.2
412 - Precondition Failed
El servidor no es capaz de cumplir con algunas de las condiciones impuestas

por el navegador en su petición.2
413 - Request Entity Too Large
La petición del navegador es demasiado grande y por ese motivo el servidor

no la procesa2
414 - Request-URI Too Long
La URI de la petición del navegador es demasiado grande y por ese motivo

el servidor no la procesa (esta condición se produce en muy raras ocasiones y casi
siempre porque el navegador envía como GET una petición que debería ser
POST).2
68
415 - Unsupported Media Type
La petición del navegador tiene un formato que no entiende el servidor y por

eso no se procesa.2
416 - Requested Range Not Satisfiable
El cliente ha preguntado por una parte de un archivo, pero el servidor no

puede proporcionar esa parte, por ejemplo, si el cliente preguntó por una parte de
un archivo que está más allá de los límites del fin del archivo.
417 - Expectation Failed
La petición del navegador no se procesa porque el servidor no es capaz de

cumplir con los requerimientos de la cabecera Expect de la petición.2
418 - I'm a teapot
"Soy una tetera". Este código fue definido en 1998 como una inocentada, en
el Protocolo de Transmisión de Hipertexto de Cafeteras (RFC-2324). No se espera
que los servidores web implementen realmente este código de error, pero es posible
encontrar sitios que devuelvan este código HTTP.
422 - Unprocessable Entity (WebDAV - RFC 4918)
La solicitud está bien formada, pero fue imposible seguirla debido a errores
semánticos.
423 - Locked (WebDAV - RFC 4918)
El recurso al que se está teniendo acceso está bloqueado.
424 - Failed Dependency (WebDAV) (RFC 4918)
La solicitud falló debido a una falla en la solicitud previa.
425 - Unassigned
Definido en los drafts de WebDav Advanced Collections, pero no está

presente en "Web Distributed Authoring and Versioning (WebDAV) Ordered
Collections Protocol" (RFC 3648).
426 - Upgrade Required (RFC 7231)
El cliente debería cambiarse a TLS/1.0.
69
428 - Precondition Required
El servidor requiere que la petición del navegador sea condicional (este tipo
de peticiones evitan los problemas producidos al modificar con PUT un recurso que
ha sido modificado por otra parte).2
429 - Too Many Requests
Hay muchas conexiones desde esta dirección de internet.
431 Request Header Fields Too Large)
El servidor no puede procesar la petición porque una de las cabeceras de la

petición es demasiado grande. Este error también se produce cuando la suma del
tamaño de todas las peticiones es demasiado grande.2
449
Una extensión de Microsoft: La petición debería ser reintentada después de

hacer la acción apropiada.
451 - Unavailable for Legal Reasons
El contenido ha sido eliminado como consecuencia de una orden judicial o

sentencia emitida por un tribunal.
70
5xx Errores de servidor
El servidor falló al completar una solicitud aparentemente válida.
Los códigos de respuesta que comienzan con el dígito "5" indican casos en
los cuales el servidor tiene registrado aún antes de servir la solicitud, que está
errado o es incapaz de ejecutar la petición. Excepto cuando está respondiendo a un
método HEAD, el servidor debe incluir una entidad que contenga una explicación de
la situación de error, y si es una condición temporal o permanente. Los agentes de
usuario deben desplegar cualquier entidad incluida al usuario. Estos códigos de
respuesta son aplicables a cualquier método de petición.
500 - Internal Server Error
Es un código comúnmente emitido por aplicaciones empotradas en

servidores web, mismas que generan contenido dinámicamente, por ejemplo
aplicaciones montadas en IIS o Tomcat, cuando se encuentran con situaciones de
error ajenas a la naturaleza del servidor web.
501 - Not Implemented
El servidor no soporta alguna funcionalidad necesaria para responder a la

solicitud del navegador (como por ejemplo el método utilizado para la petición).
502 - Bad Gateway
El servidor está actuando de proxy o gateway y ha recibido una respuesta

inválida del otro servidor, por lo que no puede responder adecuadamente a la
petición del navegador.
503 - Service Unavailable
El servidor no puede responder a la petición del navegador porque está

congestionado o está realizando tareas de mantenimiento.
504 - Gateway Timeout
El servidor está actuando de proxy o gateway y no ha recibido a tiempo una

respuesta del otro servidor, por lo que no puede responder adecuadamente a la
petición del navegador.
505 - HTTP Version Not Supported
El servidor no soporta o no quiere soportar la versión del protocolo HTTP

utilizada en la petición del navegador.
71
506 - Variant Also Negotiates (RFC 2295)
El servidor ha detectado una referencia circular al procesar la parte de la

negociación del contenido de la petición.
507 - Insufficient Storage (WebDAV - RFC 4918)
El servidor no puede crear o modificar el recurso solicitado porque no hay

suficiente espacio de almacenamiento libre.
508 - Loop Detected (WebDAV)
La petición no se puede procesar porque el servidor ha encontrado un bucle

infinito al intentar procesarla.
509 - Bandwidth Limit Exceeded
Límite de ancho de banda excedido. Este código de estatus, a pesar de ser

utilizado por muchos servidores, no es oficial.
510 - Not Extended (RFC 2774)
La petición del navegador debe añadir más extensiones para que el servidor
pueda procesarla.
511 - Network Authentication Required
El navegador debe autenticarse para poder realizar peticiones (se utiliza por
ejemplo con los portales cautivos que te obligan a autenticarte antes de empezar a
navegar).
512 - Not updated
Este error prácticamente es inexistente en la red, pero indica que el servidor

está en una operación de actualizado y no puede tener conexión.
72

Proyecto de Título RPA - Final

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Proyecto de Título RPA - Final

Загружено:

Авторское право:

Доступные форматы

INSTITUTO PROFESIONAL SANTO TOMÁS

SEDE San Joaquín

Alumno: Marco Soruco Hurtado

El presente proyecto va dedicado a Cynthya mi mujer y pilar fundamental en mi vida,

A mis padres y familia, por sus consejos y ayuda.

A todos ustedes, con amor, se merecen esto y mucho más.

Presentación del Proyecto de Título………………………………………………….. i

Glosario, abreviaturas y simbología………………………………………………….. vii

I.2 Objetivos del Proyecto…………………………………………...………….…. 2

II. DESARROLLO DEL PROYECTO…………………………………..……………. 3

II.1 Descripción de la empresa, institución o área TI………………..…….……. 3

II.2 Descripción de las tareas desarrolladas en la práctica profesional………. 4

II.3 Planificación y Metodología del Proyecto…………………...………………. 5

II.4 Descripción del Desarrollo del Proyecto…………………...………………. 9

III. PRODUCTO FINAL……………………...…………………………………………. 31

III.1 Presentación del Problema………………………………..…………………. 31

III.2 Desarrollo del Problema………………………..………………………………. 37

IV. ASPECTOS COMPLEMENTARIOS…………………..…………………………. 61

Tabla 1 - Sprints Planificación Proyecto .................................................................................... 5

Ilustración 1 Carta Gantt Implementación ............................................................................... 5

Middleware: Middleware es software que se sitúa entre un sistema operativo y las

Framework: Un framework, entorno de trabajo o marco de trabajo2 es un conjunto

API: Una API es un conjunto de funciones y procedimientos que cumplen una o

Patrón de Diseño: En programación a veces nos encontramos con ciertos problemas

ORM: Object-Relational mapping, o lo que es lo mismo, mapeo de objeto-relacional,

TMO: Tiempo medio de Operación corresponde al tiempo que demora un ejecutivo

SLA: Service Level Agreement, como concepto es un acuerdo entre cliente y

Autor: Marco Antonio Soruco Hurtado

Palabras Claves: RPA, Robot, Automatización, Usuario

El proyecto desarrollara una plataforma integral para la automatización de procesos

Entrando a un ámbito más técnico, implementaremos una plataforma compuesta de

Analizaremos los pasos que componen la ejecución de un agendamiento de Equipos,

Actualmente existen diversas tareas BackOffice que son voluminosas y repetitivas

Cuando se habla de robots tendemos a pensar en máquinas pesadas que llevan a

La capacidad de procesamiento de los equipos computacionales modernos, así como

A. El objetivo principal del proyecto consiste en implementar una plataforma integral,

C. Implementar un cuadro de mando web, con reportes encargados de mostrar el

E. Implementar un robot RPA, que será el encargado de ejecutar todas las

II.1 Descripción de la empresa, institución o área TI

Esta empresa es proveedora de Servicios de Outsourcing de Procesos, de Soluciones

Trabaja de manera flexible y responsable, adaptándose con agilidad a las cambiantes

Encargado de realizar el levantamiento, desarrollar y gestionar proyectos, para áreas

Estos proyectos, principalmente consisten en automatizar, optimizar y garantizar el

Funciones específicas del puesto:

A continuación, se detallan las funciones que deben ser realizadas en el puesto de

- Toma de requerimientos con clientes de áreas internas y externas (Telefónica

Planificación del proyecto

La fecha de inicio para la implementación de nuestro proyecto será el 01 de diciembre

En la implementación de nuestro proyecto, dividiremos nuestro proyecto en tres hitos

Hito Principal Duración Inicio Fin

Finalmente se adjunta la imagen de la carta Gantt del proyecto, en la cual se detalla

Ilustración 1 Carta Gantt Implementación – Fuente: Elaboración Propia

En la actualidad los proyectos informáticos se desarrollan bajo contextos muy

La metodología que utilizaremos en este proyecto será Scrum. A continuación,

Scrum es un método para trabajar en equipo a partir de iteraciones o Sprints. Así

Se suele planificar por semanas. Al final de cada Sprint o iteración, se va revisando

La metodología Scrum se centra en ajustar sus resultados y responder a las

Entre las principales características de la metodología Scrum, destaca que es un

Además, en la metodología Scrum se solapan diferentes fases de desarrollo, en lugar

1. Reunión para la planificación del Sprint. En ella, se divide el tiempo de duración

2. Scrum diario: Se basa en poner en común y sincronizar actividades para elaborar

3. Trabajo de desarrollo durante el Sprint: Nos aseguramos que los objetivos se