Está en la página 1de 34

UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA

VICERRECTORADO ACADÉMICO

COORDINACIÓN GENERAL DE PREGRADO

COORDINACIÓN DE PASANTÍA

COORDINACIÓN DE INGENIERÍA EN INFORMÁTICA

NEXIA C.A

DESARROLLO DE UNA APLICACIÓN WEB PARA LA GESTIÓN DE


PROYECTOS DE LA EMPRESA NEXIA C.A

Informe de pasantía presentado como requisito académico, para optar por el


título de Ingeniero en Informática

Tutor académico:

Alejandro Marcus C.I: 13.837.512

Tutor industrial: Autor:

Ronald Boada C.I: 21.339.525 Br. Jesús Soledad C.I: 25.324.227

PUERTO ORDAZ, OCTUBRE 2018


ÍNDICE

ÍNDICE DE FIGURAS......................................................................................vi

1. INTRODUCCIÓN........................................................................................7

2. DESCRIPCIÓN DE LA EMPRESA............................................................8

2.1 IDENTIFICACIÓN DE LA EMPRESA.....................................................8

2.2 MISIÓN....................................................................................................8

2.3 VISIÓN.....................................................................................................9

3. ACTIVIDAD ASIGNADA.............................................................................9

4. DESCRIPCIÓN DEL PLAN DE TRABAJO................................................9

4.1 RECOPILACIÓN Y ANÁLISIS DE LOS REQUERIMIENTOS..............10

4.2 ELABORACIÓN DE DIAGRAMA DE ENTIDAD RELACIÓN Y CASOS

DE USO.......................................................................................................10

4.3 DESARROLLO DE LA BASE DE DATOS EN POSTGRESQL............10

4.4 DESARROLLO DE LA API RESTFUL CON EL FRAMEWORK

LOOPBACK.................................................................................................10

4.5 DESARROLLO DE LA APLICACIÓN WEB CON EL FRAMEWORK

ANGULAR...................................................................................................11

4.6 PRUEBAS Y CORRECCIONES...........................................................11

4.7 ELABORACIÓN DEL MANUAL DE USUARIO.....................................11


4.8 INSTALACIÓN DE TODO EL SISTEMA EN UN SERVIDOR DE

PRODUCCIÓN............................................................................................11

5. OBJETIVO................................................................................................11

6. PROCEDIMIENTOS EMPLEADOS.........................................................12

6.1 DIAGRAMA DE ENTIDAD RELACIÓN.................................................12

6.2 DIAGRAMAS DE CASOS DE USO......................................................12

6.3 METODOLOGÍA....................................................................................15

6.4 DESARROLLO DE LA API RESTFUL CON EL FRAMEWORK

LOOPBACK.................................................................................................17

6.4.1 DEFINICIÓN DE LOS MODELOS..................................................18

6.5 DESARROLLO DE LA APLICACIÓN WEB CON EL FRAMEWORK

ANGULAR...................................................................................................20

6.5.1 DASHBOARD.................................................................................21

6.5.2 AGREGAR NUEVO PROYECTO...................................................21

6.5.3 INFORMACIÓN DE UN PROYECTO.............................................22

6.5.4 MODIFICAR UN PROYECTO........................................................24

6.5.5 NUEVA TAREA...............................................................................24

6.5.6 INFORMACIÓN DE UNA TAREA...................................................25

6.5.7 MODIFICAR UNA TAREA..............................................................26

6.5.8 USUARIOS.....................................................................................26
6.5.9 NUEVO USUARIO..........................................................................27

6.5.10 MODIFICAR UN USUARIO..........................................................27

6.6 PRUEBAS..............................................................................................29

6.7 DOCUMENTACIÓN..............................................................................29

7. FACILIDADES Y DIFICULTADES..............................................................29

7.1 FACILIDADES.......................................................................................29

7.2 DIFICULTADES.....................................................................................30

8. CONCLUSIONES.......................................................................................30

9. RECOMENDACIONES...............................................................................30

10. GLOSARIO................................................................................................31

11. REFERENCIAS.........................................................................................32
ÍNDICE DE FIGURAS

Figura 1. Plan de Trabajo. Fuente: Elaboración propia, Jesús Soledad (2018).

.........................................................................................................................10

Figura 2. Diagrama de entidad relación. Fuente: Elaboración propia, Jesús

Soledad (2018)................................................................................................12

Figura 3. Diagrama de casos de uso para el administrador. Fuente:

Elaboración propia, Jesús Soledad (2018).....................................................13

Figura 4. Diagrama de casos de uso para el CTO. Fuente: Elaboración

propia, Jesús Soledad (2018).........................................................................14

Figura 5. Diagrama de casos de uso para el programador y diseñador.

Fuente: Elaboración propia, Jesús Soledad (2018)........................................15

Figura 6. Explorador de los endpoints de la API de LoopBack. Fuente:

Elaboración propia, Jesús Soledad (2018).....................................................18

Figura 7. Dashboard de la aplicación web. Fuente: Elaboración propia, Jesús

Soledad (2018)................................................................................................21

Figura 8. Vista para crear un nuevo proyecto. Fuente: Elaboración propia,

Jesús Soledad (2018).....................................................................................22

Figura 9. Vista de la información de un proyecto parte I. Fuente: Elaboración

propia, Jesús Soledad (2018).........................................................................23

Figura 10. Vista de la información de un proyecto parte II. Fuente:

Elaboración propia, Jesús Soledad (2018).....................................................23

Figura 11. Vista para editar un proyecto. Fuente: Elaboración propia, Jesús

Soledad (2018)................................................................................................24
Figura 12. Vista para crear una nueva tarea. Fuente: Elaboración propia,

Jesús Soledad (2018).....................................................................................25

Figura 13. Vista de la información de una tarea. Fuente: Elaboración propia,

Jesús Soledad (2018).....................................................................................25

Figura 14. Vista para editar una tarea. Fuente: Elaboración propia, Jesús

Soledad (2018)................................................................................................26

Figura 15. Vista para la gestión de usuarios. Fuente: Elaboración propia,

Jesús Soledad (2018).....................................................................................26

Figura 16. Vista para agregar un nuevo usuario. Fuente: Elaboración propia,

Jesús Soledad (2018).....................................................................................27

Figura 17. Vista para editar un usuario. Fuente: Elaboración propia, Jesús

Soledad (2018)................................................................................................28
7

1. INTRODUCCIÓN
En la actualidad las empresas de desarrollo de software cuentan con una
variedad de proyectos, con sus respectivos equipos de desarrollo, y existen
herramientas que permiten gestionarlos de una manera organizada y
eficiente. La empresa Nexia C.A cuenta con una gran variedad de proyectos
que ameritan una buena gestión y composición de equipos que los
conforman, debido a esto se solicita el desarrollo de una aplicación web que
se adapte sólo a las necesidades puntuales de la empresa. Los
procedimientos empleados fueron: los diagramas de casos de uso y el
diagrama entidad relación, los cuales permitieron definir la estructura de la
base de datos y las funciones básicas de cada tipo de usuario. La
metodología ágil SCRUM fue la seleccionada debido a que la empresa Nexia
C.A la utiliza para sus proyectos. Se realizó el desarrollo de la api RESTful
con el framework LoopBack y luego se desarrolló la aplicación web con el
framework Angular que consume los servicios de la api RESTful. Se logró el
desarrollo de una aplicación web que cumple con las necesidades
inmediatas de la empresa con una buena base para que la misma sea
escalable y se le pueda dar mantenimiento y soporte.

En el contenido del presente informe se refleja la información detallada sobre


la empresa con su identificación, misión y visión. Se explica la actividad
asignada presentando la situación actual de la empresa y la justificación del
desarrollo de la aplicación web. Así mismo, se define el objetivo del trabajo
de pasantía.

Seguidamente, se describe el plan de trabajo acordado con la empresa y


posteriormente aprobado por la universidad explicando cada punto del
mismo. Luego se detallan los procedimientos empleados: diagrama de
entidad relación, diagramas de casos de uso, la metodología empleada, el
desarrollo de la api RESTful, el desarrollo de la aplicación web con la
explicación de cada vista, las pruebas realizadas y la documentación.
8

Posteriormente se presentan las facilidades y dificultades encontradas al


momento de realizar la pasantía, las conclusiones, recomendaciones, el
glosario y las referencias de todo el informe.

2. DESCRIPCIÓN DE LA EMPRESA
La empresa Nexia C.A es una empresa que ofrece servicios informáticos,
orientados principalmente al desarrollo y mantenimiento de tiendas online
utilizando CMS, entre los cuales destacan PrestaShop, WordPress y
Magento. La empresa cuenta con dos departamentos, el departamento
administrativo y el departamento de desarrollos informáticos, siendo este
último donde se llevó a cabo el desarrollo de la pasantía.

El departamento de desarrollos informáticos cuenta con un director de


tecnología (CTO por sus siglas en inglés), el cual se encarga de organizar los
equipos de trabajo por proyecto, participa como intermediario entre los
clientes y los desarrolladores, y también tiene una participación dentro de los
equipos de proyecto, en los que cumple el rol de gestor y en algunos casos
como parte del equipo de desarrollo o mantenimiento. El director ejecutivo de
la empresa (CEO por sus siglas en inglés), quien es la persona encargada de
buscar nuevos proyectos, asignarlos y llevar un seguimiento de cada uno de
ellos. Y los desarrolladores, quienes forman parte de la empresa y son
asignados a diferentes proyectos por el CTO.

2.1 IDENTIFICACIÓN DE LA EMPRESA

La empresa se constituye a partir de un equipo experimentado de


ingenieros informáticos trabajando en la realización y creación de comercios
electrónicos a medida y artesanales desde 1999, partiendo siempre de la
base del software libre (PrestaShop, Magento, entre otros).

2.2 MISIÓN
Asegurar la continuidad y prosperidad sin ninguna clase de ataduras de
una tienda online, que en todo momento será propiedad del cliente.
9

2.3 VISIÓN
Empresa líder de eCommerce en el mundo usando herramientas como
PrestaShop, Magento y WooCommerce enriqueciendo así el potencial en las
mismas.

3. ACTIVIDAD ASIGNADA
En la actualidad las empresas de desarrollo de software cuentan con una
variedad de proyectos, con sus respectivos equipos de desarrollo, y existen
herramientas como Trello que permiten gestionarlos de una manera
organizada y eficiente.

La empresa Nexia C.A cuenta con una cantidad considerable de proyectos


que con el pasar del tiempo va incrementando (como también disminuye al
finalizar alguno de ellos). Esto amerita una buena gestión de cada uno de
ellos y de los equipos que los conforman.

El CEO se ha rehusado a utilizar las herramientas ya existentes de gestión


de proyectos como Trello por la razón de que tienen muchas funcionalidades
que no son necesarias para la empresa; atrasarían y harían más engorroso
el proceso de gestión de los proyectos por parte del CEO ya que este desea
tener un seguimiento de todos los proyectos y necesita información de cada
uno de ellos y sus tareas respectivas. Hasta ahora, la gestión de proyectos la
realiza a través de herramientas básicas como Google Hangouts (para la
comunicación con el CTO y los desarrolladores por cada proyecto) y Google
Docs (para crear documentos por cada proyecto con la información del
mismo). Se requería entonces el desarrollo de una aplicación web que se
adaptara sólo a las necesidades puntuales de la empresa.

4. DESCRIPCIÓN DEL PLAN DE TRABAJO


Se describen las actividades realizadas que fueron acordadas con la
empresa a través del plan de trabajo aprobado que se muestra en la figura 1.
10

Figura 1. Plan de Trabajo. Fuente: Elaboración propia, Jesús Soledad (2018).

4.1 RECOPILACIÓN Y ANÁLISIS DE LOS REQUERIMIENTOS


En esta actividad, se recopilaron y analizaron los requerimientos
funcionales y no funcionales, para tener una visión clara de las necesidades
que se debían satisfacer y los objetivos que debía cumplir la aplicación que
fue desarrollada.

4.2 ELABORACIÓN DE DIAGRAMA DE ENTIDAD RELACIÓN Y CASOS


DE USO
Una vez analizados los requerimientos se procedió a elaborar los
diagramas para visualizar de una manera más concreta las entidades
involucradas y los procesos correspondientes.

4.3 DESARROLLO DE LA BASE DE DATOS EN POSTGRESQL


Se hizo el desarrollo de la base de datos a partir del diagrama de entidad
relación con todas las tablas, y sus campos correspondientes, necesarias
para cada entidad y las relaciones que tienen entre ellas.

4.4 DESARROLLO DE LA API RESTFUL CON EL FRAMEWORK


LOOPBACK
Se desarrolló la api RESTful a partir del modelo de base de datos diseñado
siguiendo la documentación del framework LoopBack con todos los
11

endpoints para crear, leer, modificar y eliminar la información de todas las


entidades.

4.5 DESARROLLO DE LA APLICACIÓN WEB CON EL FRAMEWORK


ANGULAR
Se desarrolló la aplicación web en Angular, que sirve como interfaz gráfica
de usuario consumiendo los servicios del api RESTful desarrollada
previamente, siguiendo su documentación, el diagrama de casos de uso y los
requerimientos definidos.

4.6 PRUEBAS Y CORRECCIONES


Se realizaron las pruebas finales de todo el flujo de la aplicación y se hizo
la corrección de errores necesaria para que la aplicación web pudiera ser
desplegada en un ambiente de producción.

4.7 ELABORACIÓN DEL MANUAL DE USUARIO


Se elabora el manual de usuario de la aplicación explicando
detalladamente sus características y cada funcionalidad disponible.

4.8 INSTALACIÓN DE TODO EL SISTEMA EN UN SERVIDOR DE


PRODUCCIÓN
Una vez realizadas las pruebas se confirmó que la aplicación estaba apta
para producción y se procedió a desplegar la aplicación web, en un servidor
privado de la empresa, que estará disponible para todos los usuarios de la
misma (CEO, CTO, desarrolladores y diseñadores).

5. OBJETIVO
Desarrollar una aplicación web para la gestión de proyectos de la empresa
NEXIA C.A.
12

6. PROCEDIMIENTOS EMPLEADOS.
6.1 DIAGRAMA DE ENTIDAD RELACIÓN
Se elaboró el diagrama de entidad relación de acuerdo a los
requerimientos recolectados. Como se muestra en la figura 2.

Figura 2. Diagrama de entidad relación. Fuente: Elaboración propia, Jesús


Soledad (2018).

6.2 DIAGRAMAS DE CASOS DE USO


Se elaboraron los diagramas para cada tipo de usuario de la aplicación
web. Como se muestra en las figuras 3, 4 y 5.
13

Figura 3. Diagrama de casos de uso para el administrador. Fuente:


Elaboración propia, Jesús Soledad (2018).

Caso de uso Usuario con el rol de Importancia Alta


administrador
Descripción El administrador además de gestionar los proyectos, gestiona todos
los usuarios, siendo así el único que puede registrar nuevos
usuarios, modificarlos y eliminarlos en la aplicación web además de
ser el único que puede agregar, modificar y eliminar proyectos.
Flujo normal
1 El administrador agrega nuevos usuarios.
2 Agrega un nuevo proyecto, asigna los integrantes y el líder.
3 Visualiza la lista de proyectos, la información detallada de uno de ellos y agrega
tareas al mismo asignando a su vez el encargado en cada una de ellas.
4 Agrega comentarios en el proyecto y sus tareas.
14

Figura 4. Diagrama de casos de uso para el CTO. Fuente: Elaboración


propia, Jesús Soledad (2018).

Caso de uso Usuario con el rol de Importancia Alta


CTO
Descripción El CTO puede ver la información de todos los proyectos, asignar
integrantes y el líder de cada uno de ellos al igual que el
Administrador. De las tareas en los proyectos sólo puede asignar al
encargado y modificar el estado de las mismas.
Flujo normal
1 El CTO visualiza la lista de proyectos y la información detallada sobre uno de ellos.
2 Asigna nuevos integrantes al proyecto y los asigna como encargados de las tareas
que van a realizar.
3 Cambia el estado de las tareas si es necesario.
4 Agrega comentarios en el proyecto y sus tareas.
15

Figura 5. Diagrama de casos de uso para el programador y diseñador.


Fuente: Elaboración propia, Jesús Soledad (2018).

Caso de uso Usuario con el rol de Importancia Alta


Programador o Diseñador
Descripción El Programador o Diseñador puede ver la información de todos los
proyectos en los que participa. De las tareas en los proyectos sólo
puede modificar el estado de las mismas.
Flujo normal
1 El Programador o Diseñador visualiza la lista de proyectos y la información
detallada sobre uno de ellos.
2 Cambia el estado de las tareas en las que es encargado.
3 Agrega comentarios en el proyecto y sus tareas.

6.3 METODOLOGÍA
Actualmente las metodologías ágiles son las más utilizadas para el
desarrollo de sistemas de información debido a que permiten mantener una
interacción directa con el cliente y realizar entregas frecuentes del producto.
Una de las metodologías ágiles más usadas es SCRUM, la cual está
diseñada para trabajar en equipos a partir de iteraciones o Sprints que tienen
16

una duración entre una y cuatro semanas máximo. Un proyecto está


compuesto por varios Sprints.

Dentro del desarrollo de un Sprint se llevan a cabo ciertos eventos, reciben el


nombre de SCRUM Events o Eventos SCRUM, estos son: Planeación del
Sprint, reunión de equipo de SCRUM o SCRUM diario, refinamiento de
Backlog, revisión del Sprint y retrospectiva del Sprint (Lara, 2015, párr. 8).

En el equipo de SCRUM los participantes pueden ejercer diversos roles.


Entre ellos destacan: Product Owner o Dueño del Producto quien es el
responsable de desarrollar, mantener y priorizar las tareas; SCRUM Master
quien está a cargo de la supervisión del equipo y los Development Team
Members o Miembros del Equipo de Desarrollo, encargados de llevar a cabo
todas las actividades asociadas al desarrollo del software.

La empresa Nexia C.A utiliza como metodología principal en el desarrollo de


sistemas la metodología ágil SCRUM, pues la mayoría de los proyectos se
abordan en equipos y tienen interacción constante con el cliente. Por tal
motivo la empresa solicitó utilizar la misma metodología, pero con cambios
en la misma para que pueda ser empleada por una sola persona ya que el
proyecto fue realizado de manera individual. Además, gracias al SCRUM el
CEO tiene una participación constante en el desarrollo del proyecto,
cumpliendo el papel en el SCRUM como el Product Owner. Por otra parte, el
SCRUM Master sería el tutor industrial.

Las fases de la metodología aplicada son:

 Planificación de Sprints. Junto con el CEO y el tutor industrial, se


llevó a cabo una reunión en la que se definieron los Sprints, su
duración y los objetivos a cumplir en cada uno de ellos.
17

 SCRUM diario. Reunión diaria con el CEO y el tutor industrial de 15


minutos aproximadamente, para planificar la actividad a realizar ese
día y revisar los avances en la actividad del día anterior.
 Desarrollo del Sprint. Una vez realizado el SCRUM diario, se
comenzó a trabajar sobre el Sprint.
 Revisión o demostración del Sprint. Como cada Sprint fue
planificado semanalmente, cada viernes se realizó una reunión con el
tutor industrial, que evaluó los avances realizados durante el sprint.
Se realizaron pruebas y se registraron los cambios correspondientes
a errores o recomendaciones acotadas por el tutor industrial.

Debido a la naturaleza del SCRUM las fases se repitieron durante toda la


duración del proyecto hasta la entrega final.

6.4 DESARROLLO DE LA API RESTFUL CON EL FRAMEWORK


LOOPBACK
Se generó el proyecto usando los comandos disponibles en LoopBack y se
generaron los endpoints correspondientes para cada entidad: usuarios,
comentarios, proyectos, roles y tareas.

Luego se crearon todos los modelos con su conexión a la base de datos de


cada entidad y se desarrollaron los métodos necesarios para iniciar sesión,
crear, leer, modificar y eliminar información. Adicionalmente se configuró la
autenticación para los endpoints con una capa de seguridad que verifica un
token enviado en cada petición que se hace a la api.

En la figura 6 se muestra el explorador de LoopBack de la api.


18

Figura 6. Explorador de los endpoints de la API de LoopBack. Fuente: Elaboración


propia, Jesús Soledad (2018)

6.4.1 DEFINICIÓN DE LOS MODELOS


Todos los modelos tienen definidos sus atributos propios más los típicos
created_at y updated_at que permiten tener un control de la fecha y hora de
creación y actualización de la información en cada entidad.

6.4.1.1 USUARIOS (USERS). Los usuarios necesarios para mantener una


sesión en la aplicación web e interactuar con la misma. Tiene los atributos:
id, nombre, apellido, correo y contraseña. Las relaciones son las siguientes:

 El modelo de usuarios se relaciona con los proyectos a través de


una relación de muchos a muchos con una tabla
proyectos_usuarios ya que un usuario puede participar en muchos
proyectos y en los proyectos participan muchos usuarios.
 También se relaciona con los proyectos a través de una relación
de uno a muchos ya que un usuario lidera muchos proyectos y un
proyecto es liderado por un solo usuario.
 Se relaciona con el modelo de roles a través de una relación de
muchos a muchos con una tabla usuarios_roles ya que un usuario
puede tener muchos roles y los roles pertenecen a muchos
19

usuarios. En los roles inicialmente se cuenta con: administrador,


CTO, programador y diseñador.
 Los usuarios se relacionan con el modelo de comentarios a través
de una relación de uno a muchos ya que un usuario genera
muchos comentarios y los comentarios son generados por un solo
usuario.
 Se relacionan con el modelo de tareas a través de una relación de
uno a muchos ya que un usuario es encargado de muchas tareas
y una tarea solo puede tener un encargado.

6.4.1.2 PROYECTOS (PROJECTS). El modelo de proyecto es bastante


importante ya que se definió para almacenar información sobre los proyectos
de la empresa cumpliendo así con el objetivo de este trabajo de gestionar los
proyectos. Tiene los atributos: id, nombre, descripción y fecha límite. Las
relaciones son las siguientes:

 Se relacionan con el modelo de usuarios.


 Se relacionan con el modelo de tareas a través de una relación de
uno a muchos ya que los proyectos tienen muchas tareas y una
tarea pertenece a un solo proyecto.
 Se relacionan con el modelo de comentarios a través de una
relación de uno a muchos ya que un proyecto tiene muchos
comentarios y un comentario pertenece a solo un proyecto.

6.4.1.3 TAREAS (TASKS). Las tareas se definieron para almacenar las


actividades que se van a realizar en cada proyecto. Tiene los atributos: id,
descripción y finalizada (booleano que almacena el estado de la misma). Las
relaciones son las siguientes:

 Se relacionan con el modelo de proyectos.


 Se relacionan con el modelo de usuarios.
20

 El modelo de tareas se relaciona con el modelo de comentarios


a través de una relación de uno a muchos ya que una tarea tiene
muchos comentarios y un comentario pertenece a solo una
tarea.

6.4.1.4 ROLES (ROLES). El modelo de roles se definió para almacenar los


roles que tienen los usuarios y así declarar una serie de permisos a partir de
los mismos. Tiene los atributos: id, nombre y descripción. Los roles solo se
relacionan con el modelo de usuarios.

6.4.1.5 COMENTARIOS (COMMENTS). El modelo de comentarios se


definió para almacenar algún comentario, duda o información adicional sobre
un proyecto o una tarea. Tiene como atributos: id y contenido. Los
comentarios pueden pertenecer a un proyecto o una tarea, no pueden
pertenecer a ambos simultáneamente. Las relaciones son las siguientes:

 Se relacionan con el modelo de usuarios.


 Se relacionan con el modelo de tareas.
 Se relacionan con el modelo de proyectos.

6.5 DESARROLLO DE LA APLICACIÓN WEB CON EL FRAMEWORK


ANGULAR
Una vez finalizada la api y los endpoints necesarios se inició el proyecto en
Angular. En el transcurso del desarrollo de la aplicación web se tuvieron que
realizar pequeñas modificaciones en la api RESTful debido a los cambios
que surgieron el algunos Sprints de acuerdo a la metodología aplicada y los
requerimientos del CEO. La interfaz de usuario de la aplicación web cuenta
distintas vistas que consumen cada uno de los endpoints de la api RESTful
para presentar toda la información y en algunos casos agregar, modificar y
eliminar cierta información.
21

A continuación, se describen las vistas principales manteniendo una sesión


con el rol de administrador.

6.5.1 DASHBOARD
Se presenta la lista de proyectos con la información de cada uno de ellos.
En la misma existe la opción de ir a la vista de un nuevo proyecto o la vista
de la información más detallada de uno de ellos y eliminar un proyecto.
Como se muestra en la figura 7.

Figura 7. Dashboard de la aplicación web. Fuente: Elaboración propia, Jesús


Soledad (2018).

6.5.2 AGREGAR NUEVO PROYECTO.


En esta vista se solicita a través de un formulario toda la información
necesaria para crear un nuevo proyecto. Como se muestra en la figura 8.
22

Figura 8. Vista para crear un nuevo proyecto. Fuente: Elaboración propia,


Jesús Soledad (2018).

6.5.3 INFORMACIÓN DE UN PROYECTO.


En esta vista se presenta la información más detallada de un proyecto.
Cuenta con la lista de integrantes (identificando al líder del proyecto), lista de
tareas y lista de comentarios. El usuario tiene la opción de modificar un
proyecto, agregar una nueva tarea al proyecto, ir a la vista de la información
de una tarea, eliminar una tarea, agregar un nuevo comentario y eliminar uno
de ellos. Como se muestra en las figuras 9 y 10.
23

Figura 9. Vista de la información de un proyecto parte I. Fuente: Elaboración


propia, Jesús Soledad (2018).

Figura 10. Vista de la información de un proyecto parte II. Fuente:


Elaboración propia, Jesús Soledad (2018).
24

6.5.4 MODIFICAR UN PROYECTO.


En esta vista se solicita a través de un formulario toda la información
necesaria para editar un proyecto. Como se muestra en la figura 11.

Figura 11. Vista para editar un proyecto. Fuente: Elaboración propia, Jesús
Soledad (2018).

6.5.5 NUEVA TAREA.


Se solicita a través de un formulario toda la información necesaria para
crear una nueva tarea asociada a un proyecto en específico. Como se
muestra en la figura 12.
25

Figura 12. Vista para crear una nueva tarea. Fuente: Elaboración propia,
Jesús Soledad (2018).

6.5.6 INFORMACIÓN DE UNA TAREA.


Se presenta la información de una tarea con su lista de comentarios. El
usuario tiene la opción de modificar la tarea y agregar comentarios a la
misma. Como se muestra en la figura 13.

Figura 13. Vista de la información de una tarea. Fuente: Elaboración propia,


Jesús Soledad (2018).
26

6.5.7 MODIFICAR UNA TAREA.


En esta vista se solicita a través de un formulario toda la información
necesaria para editar una tarea. Como se muestra en la figura 14.

Figura 14. Vista para editar una tarea. Fuente: Elaboración propia, Jesús
Soledad (2018).

6.5.8 USUARIOS.
En esta vista se presenta al administrador la lista de usuarios con la opción
de agregar un nuevo usuario, modificar y eliminar uno de ellos. Como se
muestra en la figura 15.

Figura 15. Vista para la gestión de usuarios. Fuente: Elaboración propia,


Jesús Soledad (2018).
27

6.5.9 NUEVO USUARIO.


En esta vista se solicita a través de un formulario toda la información
necesaria para agregar un nuevo usuario. Como se muestra en la figura 16.

Figura 16. Vista para agregar un nuevo usuario. Fuente: Elaboración propia,
Jesús Soledad (2018).

6.5.10 MODIFICAR UN USUARIO.


En esta vista se solicita a través de un formulario toda la información
necesaria para editar un usuario. Como se muestra en la figura 17.
28

Figura 17. Vista para editar un usuario. Fuente: Elaboración propia, Jesús
Soledad (2018).

En las vistas descritas anteriormente se puede apreciar que se cumple con


los requerimientos de la empresa que definieron una aplicación web en la
que se permite una gestión de proyectos pudiendo agregar, modificar y
eliminar proyectos con sus tareas y comentarios sumado a una gestión de
usuarios que le permita al administrador (en este caso sería el CEO de la
empresa) agregar usuarios según el rol que tengan en la empresa y
asignarles a los mismos los proyectos en los que van a participar y las tareas
en las que va a estar encargado.

El diseño de las vistas y sus funcionalidades son parecidas para todos los
roles de usuario, cambian según los permisos que estos tengan. En el caso
del CTO, este no tiene un botón para agregar o eliminar un proyecto el en
Dashboard, no puede agregar o eliminar tareas de un proyecto, solo puede
eliminar los comentarios que el mismo haya creado y no puede acceder a las
vistas que tienen que ver con la gestión de usuarios. En el caso de los
programadores y diseñadores tienen permisos similares al CTO, solo que
estos no podrán asignar usuarios participantes en proyectos y tampoco
asignarlos como encargados de tareas.
29

6.6 PRUEBAS
De cada funcionalidad que se desarrolló en un Sprint, se realizaron
pruebas en el servidor local del equipo en el que se hizo el trabajo de
pasantía bajo la supervisión del tutor industrial. Con las pruebas funcionales
se tuvo un aseguramiento de calidad comprobando que en cada
funcionalidad se cumplía con lo previamente definido en los diagramas de
caso de uso y en la planificación del Sprint.

6.7 DOCUMENTACIÓN
Una vez que se terminó el desarrollo de la aplicación web y se comprobó
mediante las pruebas finales que la misma cumplía con los requerimientos
de la empresa, se hizo el despliegue de la aplicación y la api RESTful en el
servidor privado de la empresa. Se realizó la documentación de todo el
proceso y las acciones necesarias para posteriormente actualizar el servidor
con nuevos cambios mediante el uso de repositorios como también la
instalación de nuevas dependencias.

Además, se elaboró el manual de usuario en el que se explica


detalladamente cada funcionalidad de la aplicación web y las acciones que
tiene permitidas cada rol de usuario.

7. FACILIDADES Y DIFICULTADES

7.1 FACILIDADES
 Desarrollo de toda la aplicación con el uso de frameworks ya que
proveen herramientas y una serie de buenas prácticas que
facilitan y reducen el tiempo de desarrollo.
 Fue facilitado un ordenador con las capacidades necesarias para
llevar a cabo el desarrollo de la pasantía sin problemas.
 Recomendaciones constantes del tutor industrial y el CEO que
facilitaron la definición y el desarrollo de la aplicación web.
30

7.2 DIFICULTADES
 Tiempo muy limitado de consultas al tutor industrial y el CEO
debido a sus responsabilidades dentro de la empresa.
 Curva de aprendizaje de la herramienta LoopBack exigida por la
empresa.

8. CONCLUSIONES
Se ha desarrollado una aplicación web que cumple con las necesidades
inmediatas de la empresa con una buena base para que la misma sea
escalable y otros desarrolladores ya sean empleados de la empresa o
nuevos pasantes puedan agregar funcionalidades y hacer cambios en el
diseño de la misma.

En el transcurso de las actividades se aprendió a trabajar de una manera


muy organizada como lo plantea la metodología ágil SCRUM y a utilizar
herramientas como lo son LoopBack y Angular que en la actualidad son muy
usadas en el ámbito laboral para el desarrollo de aplicaciones web.

9. RECOMENDACIONES
En la definición del plan de trabajo el tutor industrial recomendó el uso de la
herramienta LoopBack para el desarrollo de la api RESTful que consume la
aplicación web. LoopBack a pesar de que facilita muchas herramientas y el
desarrollo en sí, el tiempo que toma aprender esta herramienta es un poco
alto y en ocasiones se siente la falta de documentación y comunidad a la
hora de resolver algún problema.

La recomendación es que, si la empresa ofrece la oportunidad de sugerir


alguna herramienta para el desarrollo, se evalúen otras que sean más
conocidas y con una mejor documentación para que la pasantía se pueda
realizar sin muchas complicaciones.
31

10. GLOSARIO

10.1 ANGULAR. “Es un Framework que facilita la creación de aplicaciones


web. Angular combina plantillas declarativas, inyección de dependencias
herramientas de extremo a extremo y las mejores prácticas para ser
aplicadas en el desarrollo FrontEnd”. (Vásquez. G, 2017, párr. 1).

10.2 API RESTFUL. “Una API RESTful, también conocida como servicio
web RESTful, se basa en la tecnología de transferencia de estado
representacional (REST), un estilo arquitectónico y un enfoque de las
comunicaciones a menudo utilizadas en el desarrollo de servicios web”.
(Rouse. M, 2019, párr. 2).

10.3 CMS. “Un CMS o Sistema de Gestión de Contenidos es un programa


que le permite al usuario un fácil manejo de información para su página de
Internet.”. (Torres. A, 2019, párr. 4).

10.4 ECOMMERCE. El eCommerce, conocido también como comercio


electrónico, es el intercambio de productos o servicios usando redes
computacionales, específicamente el Internet. (Galeano. S, 2019, párr. 3).

10.5 LOOPBACK. “LoopBack es un marco de código abierto altamente


escalable para crear API con poca o ninguna codificación y vincularlas con
fuentes de datos de back-end.”. (Korotia. Y, 2016, párr. 3).

10.6 MAGENTO. “Magento es una potente plataforma para lanzar sitios de


compra y venta de productos online. Algunas de las empresas de
eCommerce más grandes del mercado utilizan esta herramienta para mejorar
sus sitios webs.”. (Mateos. M, 2017, párr. 1).

10.7 METODOLOGÍA ÁGIL. “La metodología ágil surge como sustituto a


los métodos clásicos de gestión. La flexibilidad, la calidad y la necesidad de
entregar proyectos y productos en cortos espacios de tiempo son una
prioridad.” (Martinez. S, 2016, párr. 1).
32

10.8 PRESTASHOP. Es una plataforma diseñada en PHP con licencia de


código abierto u open source, cuya principal función y razón de ser es crear
una tienda online, para que vender productos a través de Internet. (Facchin.
J, 2018, párr. 5).

10.9 SCRUM. “SCRUM es un método de organización en las empresas


para el desarrollo de proyectos.”. (Martínez. S, 2016, párr. 9).

10.10 WOOCOMMERCE.

WooCommerce es un plugin gratuito de eCommerce que te permite


vender cualquier cosa, con elegancia. Creado para que se integre sin
problemas con WordPress, WooCommerce es la solución eCommerce
favorita en todo el mundo y ofrece un control total tanto a propietarios
de tienda como a desarrolladores. (Noguera. S, 2017, párr. 1).

10.11 WORDPRESS. “WordPress es un CMS gratuito que nos permite


tanto introducir datos como leerlos, es decir, WordPress es una plataforma
que nos permite crear páginas web de distintos tipos fácilmente.” (Rodríguez.
E, 2015, párr. 2).

11. REFERENCIAS
Facchin, J. (2018). ¿Qué es PrestaShop y por qué para crear eCommerce?
Recuperado de https://webescuela.com/que-es-prestashop/

Galeano, S. (2019). Qué es el eCommerce: definición modelos y ventajas.


Recuperado de https://marketing4ecommerce.mx/que-es-el-ecommerce/

Lara, W. (2015). ¿Cómo funciona la metodología SCRUM? Recuperado de

https://platzi.com/blog/metodologia-scrum-fases/

Korotia, Y. (2016). Why LoopBack is Better Than ExpressJS? Recuperado de


https://hackernoon.com/why-loopback-is-better-than-expressjs-bcf01de87582
33

Martínez, S. (2016) ¿Qué es la metodología ágil? Recuperado de


https://superrhheroes.sesametime.com/la-metodologia-agil/

Mateos, M. (2017). ¿Qué es y cómo funciona Magento? Recuperado de


https://www.postedin.com/blog/que-es-y-como-funciona-magento/#

Noguera, S. (2017). ¿Qué es WooCommerce y para qué sirve? Recuperado


de https://ascenso.org/categoria/actualidad-digital/que-es-woocommerce-y-
para-que-sirve/

Rodríguez, E. (2015). WordPress, ¿qué es y para qué funciona? Recuperado


de https://rootear.com/web/que-es-wordpress

Torres, A. (2019). ¿Qué es un CMS y para qué sirve? Recuperado de


https://www.comparahosting.com/p/que-es-un-cms/

También podría gustarte