Universidad ORT Uruguay Facultad de Ingeniería
Gestión de procesos para Tres Cruces
Entregado como requisito para la obtención del título de Licenciado en Sistemas
Cristian Palo – 105754 Estefanía Almeyda – 194361
Joaquina Rosillo – 201529
Tutora: Jimena Saavedra
2022
2
Declaración de autoría
Nosotros, Cristian Palo, Estefanía Almeyda y Joaquina Rosillo, declaramos que el trabajo que se presenta en esa obra es de nuestra propia mano. Podemos asegurar que:
La obra fue producida en su totalidad mientras realizábamos el proyecto final de carrera de Licenciatura en Sistemas;
Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;
Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excepción de estas citas, la obra es enteramente nuestra;
En la obra, hemos acusado recibo de las ayudas recibidas;
Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos explicado claramente qué fue contribuido por otros, y qué fue contribuido por nosotros;
Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se han realizado las aclaraciones correspondientes.
Estefanía Almeyda Joaquina Rosillo Cristian Palo
3
Dedicatoria
El presente trabajo está dedicado en su totalidad a nuestras familias, que durante estos años de carrera nos han apoyado de manera incondicional para poder cumplir con el objetivo planteado.
Asimismo, a nuestros amigos y compañeros de generación que indudablemente nos han acompañado, apoyado y nos han hecho crecer.
4
Agradecimientos
En primer lugar, queremos agradecer a todos los profesionales y docentes de la Universidad ORT Uruguay; por habernos acompañado y guiado en las instancias de revisiones como lo fueron: Pablo Hernández y Marcelo Cagnani. También a Martin Solari quien nos asesoró en temas puntuales sobre usabilidad. Sin dudas sus comentarios y concejos en las diferentes etapas nos fueron aportadando valor al trabajo final.
Un agradecimiento muy especial a nuestra tutora Jimena Saavedra, quien en base a su experiencia y dedicación, nos guio, aconsejó y exigió a realizar el mejor trabajo posible atendiendo y contemplando el factor humano. Sin duda como equipo nos sentimos muy orgullosos de haberla contactado para trabajar en conjunto.
Por otro lado, agradecer a Gonzalo Gonzales y Nelson Pereyra del Shopping Tres Cruces por su disponibilidad y dedicación a lo largo del proyecto. Ellos fueron factores claves para poder desarrollar y aplicar los conocimientos académicos adquiridos a lo largo de la carrera.
5
Abstract
En este documento se presenta el trabajo de proyecto final de carrera de Licenciatura en Sistemas de la Universidad ORT, en adelante la Universidad, realizado por los estudiantes Cristian Palo, Estefanía Almeyda y Joaquina Rosillo.
El cliente es el área de Operaciones del Shopping Tres Cruces y planteó su necesidad en la feria de Proyectos de la Universidad.
El problema radica en que el registro de las tareas diarias que realiza dicha área, entendiendo como tarea a todo mantenimiento y/o mejora que se realiza en el Shopping, ya sean arreglos de escaleras mecánicas en mal funcionamiento, arreglos de carteles rotos, cambios de lámparas o luminarias, reformas del predio, entre otras;
se hace en varios canales: papel, archivos Excel y mail, lo cual dificulta el seguimiento de las mismas, ya que no siempre se actualiza el estado en todos los formatos.
La propuesta de solución del equipo es realizar una reingeniería de procesos para sus tareas, mediante la implementación de un sistema de gestión interno que tiene como fin unificar un solo canal de registro, donde todos los interesados tengan acceso a él y puedan ir alimentando la información en este sistema, de manera que todos vean dinámicamente el estado de cada tarea y en un mismo lugar.
Este documento se compone de los siguientes capítulos: introducción, cliente, contexto, problema, solución propuesta por el equipo y todo lo relacionado al ciclo del desarrollo del software que forma parte de dicha solución, como son: ingeniería de requerimientos, arquitectura del software, herramientas utilizadas, gestión del proyecto, gestión de la comunicación, gestión de riesgos, gestión de calidad y conclusiones.
6
Palabras clave
Shopping Tres Cruces Operaciones
Recorrido Actividad Objetivo Proyecto Genexus
7
Índice
Glosario ... 11
1. Introducción ... 12
1.1. Composición del equipo ... 12
1.2. Elección del proyecto ... 12
1.3. Descripción del cliente ... 13
1.4. Objetivos ... 13
1.4.1. Objetivos del equipo ... 13
1.4.2. Objetivos del proyecto ... 13
2. Contexto ... 14
2.1. Estructura ... 15
2.1.1. Recorridos ... 15
2.1.2. Actividades... 16
2.1.3. Proyectos ... 17
2.1.4. Objetivos ... 18
3. Problema ... 20
3.1. Explicación ... 20
3.2. Necesidad usuario final ... 21
3.3. Necesidad usuario gestión ... 21
4. Solución ... 23
4.1. Propuesta del equipo ... 23
5. Ingeniería de requerimientos ... 27
5.1. Proceso ... 27
5.2. Alcance ... 28
5.2.1. Restricciones ... 29
5.3. Fuera de alcance ... 29
5.4. Entregables ... 30
5.4.1. Software ... 30
5.4.2. Ejecutable ... 31
5.4.3. Archivos ... 31
5.4.4. Guía de usuarios ... 31
5.5. Requerimientos ... 31
5.5.1. Actores ... 31
5.5.2. Requerimientos funcionales ... 32
8
5.5.3. Requerimientos no funcionales ... 39
5.5.4. Requerimientos fuera de alcance ... 41
6. Arquitectura ... 42
6.1. Introducción ... 42
6.2. Atributos de calidad ... 42
6.2.1. Usabilidad ... 42
6.2.2. Portabilidad ... 42
6.2.3. Seguridad ... 43
6.3. Infraestructura ... 43
6.4. Tecnologías utilizadas ... 43
6.4.1. Genexus ... 43
6.4.2. Tomcat ... 45
6.4.3. Genexus Server ... 46
6.4.4. SQL Server ... 46
6.5. Descripción de la arquitectura ... 46
6.5.1. Backend ... 46
6.5.2. Frontend ... 48
6.5.3. Base de datos ... 48
7. Gestión de la configuración ... 51
7.1. Elementos de la configuración ... 51
7.2. Gestión de la configuración del software ... 51
7.3. Gestión de la documentación ... 52
8. Plan y gestión del proyecto ... 53
8.1. Ciclo de vida y metodología ... 53
8.1.1. Ciclo de vida ... 53
8.1.2. Metodología ... 55
8.2. Etapas del proyecto ... 55
8.2.1. Asignación de roles y responsabilidades ... 56
8.2.2. Disponibilidad del equipo ... 57
8.2.3. Estimación y planificación ... 57
9. Plan y gestión de interesados y comunicación ... 63
9.1. Plan y gestión de interesados ... 63
9.1.1. Plan de interesados ... 63
9.1.2. Gestión de interesados ... 65
9.2. Plan de comunicación ... 66
9
9.2.1. Comunicación interna ... 66
9.2.2. Comunicación externa ... 67
9.2.3. Comunicación por tutoría ... 67
10. Plan y Gestión de Riesgos... 69
10.1. Plan de riesgos ... 69
10.2. Gestión de riesgos ... 70
10.2.1. Identificación ... 70
10.3. Riesgos y planes ... 71
10.3.1. Riesgos externos ... 71
10.3.2. Riesgos tecnológicos ... 72
10.3.3. Riesgos gestión ... 72
10.3.4. Riesgos materializados ... 73
10.4. Revisión de riesgos ... 73
11. Plan y gestión de calidad ... 77
11.1. Plan de calidad ... 77
11.1.1. Objetivos de calidad ... 77
11.1.1.1. Objetivos y métricas de calidad en el proceso ... 77
11.1.1.2. Objetivos y métricas de calidad en el producto ... 78
11.2. Aseguramiento de la calidad ... 80
11.2.1. Estándares de procesos ... 81
11.2.1.1. Codificación ... 81
11.2.1.2. Documentación ... 82
11.2.2. Pruebas ... 82
11.2.2.1. Pruebas funcionales ... 83
11.2.2.2. Pruebas de usuario ... 84
11.2.2.3. Pruebas con usuario ... 84
11.2.3. Revisiones ... 85
11.3. Gestión de la calidad ... 85
11.3.1. Gestión de errores ... 86
11.3.2. Evolución de métricas ... 86
11.3.2.1. Métricas del proceso ... 86
11.3.2.2. Métricas del producto ... 89
11.3.3. Pruebas ... 92
11.3.4. Pruebas funcionales ... 92
11.3.5. Pruebas de usuario ... 92
10
11.3.6. Pruebas con usuario ... 92
11.3.7. Revisiones ... 94
12. Conclusiones ... 95
12.1. Lecciones aprendidas ... 95
12.2. Objetivos ... 96
12.2.1. Objetivos de equipo ... 96
12.2.2. Objetivos de proyecto ... 96
13. Próximos pasos ... 98
14. Referencias bibliográficas ... 99
15. Anexos ... 101
15.1. Bosquejos de pantallas ... 101
15.2. Casos de uso ... 103
15.3. Confirmación de la tecnología ... 107
15.4. Base de datos ... 108
15.4.1. Actividades ... 108
15.4.2. Objetivos ... 109
15.4.3. Proyectos ... 109
15.4.4. Seguridad ... 110
15.5. Manual de usuario ... 110
15.6. Plan de pruebas ... 141
15.7. Evidencia de las pruebas ... 142
15.7.1. Pruebas Funcionales ... 142
15.7.2. Pruebas de usuario... 144
15.7.3. Pruebas con usuario ... 145
15.8. Revisiones ... 145
11
Glosario
ABM – Conjunto de operaciones programadas que permiten realizar altas, bajas y modificaciones de datos desde una fuente externa a una base de datos sin usar un gestor propio del motor de base de datos.
Demo - Demostración del software mediante videollamada compartiendo pantalla con el fin de promocionar y mostrar lo construido.
Gantt – Diagrama de la gestión del proyecto en la que se refleja la planificación por diferentes tareas en tiempo.
MVP - del inglés Minimum Viable Product, es decir, producto que cumple una cierta cantidad de características que satisfacen al cliente y proporciona la posibilidad de retroalimentación para el desarrollo futuro.
Backend – Capa de la lógica del software, procesa los datos del frontend.
Frontend – Capa de la programación que es visible para el usuario.
12
1. Introducción
En este capítulo se presenta al equipo de trabajo del proyecto, el proyecto elegido, el cliente y los objetivos.
1.1. Composición del equipo
El equipo está integrado por tres estudiantes de Licenciatura en Sistemas de la Universidad ORT Uruguay. Los miembros del equipo tienen experiencia laboral en el área de tecnología en diferentes empresas.
Los integrantes son: Cristian Palo actualmente trabaja en el área de soporte técnico en el Banco Hipotecario Del Uruguay, cuenta con una experiencia como desarrollador desde 1999; Estefanía Almeyda actualmente trabajando en Agesic como consultora para el área de Tecnologías Emergentes, tiene experiencia como desarrolladora Genexus desde el 2011; Joaquina Rosillo trabaja en Telefónica y cuenta con una experiencia como desarrolladora Genexus desde el 2015.
Como se describió, los perfiles laborales de cada integrante del equipo fueron conocidos desde el inicio del proyecto, pero hubo cierta incertidumbre en cuanto a las fortalezas y debilidades de cada uno al momento de designar los roles necesarios para el proyecto. Por esto la asignación de roles en el equipo se realizó en base a lo que cada integrante tenía mayor interés o se sentía más cómodo en trabajar.
1.2. Elección del proyecto
Para la elección del proyecto el equipo asistió a la feria de empresas que presentó la Universidad ORT Uruguay, con el fin de poder conocer todas las propuestas y discutir sobre las mismas para poder elegir una.
Luego de la feria el equipo tuvo varias reuniones en las que se discutieron las ventajas y desventajas de cada propuesta llegando a la elección de la presentada por el cliente Tres Cruces.
Se llevaron a cabo varias reuniones con el cliente para entender más de la propuesta que presentaban y poder analizar la mejor solución posible para ellos. Luego se
13 presentó esta solución en el ante proyecto y fue la que mejor se adecuaba, por lo cual se le asignó al equipo.
1.3. Descripción del cliente
El proyecto es presentado específicamente por el área de Operaciones del Shopping Tres Cruces.
Dicha área se encarga de las obras y mantenimiento de todo el edificio Tres Cruces, esto incluye: el centro comercial, terminal de ómnibus y espacios comunes. El área para cubrir es de aproximadamente de unos 100.000 metros cuadrados.
Tres cruces fue inaugurado el 16 de noviembre de 1994, donde prestaba servicio de terminal de ómnibus y centro comercial con 80 locales. Actualmente cuenta con 190 locales y es la mayor terminal de ómnibus de todo Uruguay.
1.4. Objetivos
1.4.1. Objetivos del equipo
El principal objetivo del equipo fue poder aplicar los conocimientos adquiridos durante toda la formación universitaria, pudiendo trabajar en aspectos donde los integrantes no tenían experiencia profesional.
Por otro lado, para el equipo también fue un objetivo poder obtener el título de Licenciado en Sistemas, lo que se logrará al realizar el proyecto de forma exitosa.
1.4.2. Objetivos del proyecto
Dado que el proyecto no presenta un mayor desafío tecnológico, el equipo entiende que su mayor objetivo es poder facilitar los procesos de trabajo actuales que tiene Tres Cruces con el fin de optimizar tiempos y recursos.
El objetivo principal es poder brindar una solución que aporte valor al cliente, facilitándole su forma de trabajo y haciendo más amena las tareas que resultan complicadas y tediosas.
Para poder cumplir este objetivo el equipo trabajó en conjunto con el cliente de forma de asegurar que los procesos y el desarrollo del producto a entregar agregaran valor.
14
2. Contexto
Como se mencionó en el capítulo anterior 2.3. Descripción de cliente, el proyecto es presentado por el área de Operaciones del Shopping Tres Cruces. Dicha presentación fue realizada en la feria de Proyecto de universidad ORT.
Esta área cuenta con un presupuesto anual para poder hacer frente o dar cumplimiento a las distintas actividades de mantenimiento de la infraestructura, como a nuevos desafíos propuestos por las diferentes áreas y/o la dirección. Este presupuesto es asignado por el directorio y los accionistas.
En la siguiente ilustración 1, se muestra la estructura organizativa del área de Operaciones y se mencionarán los interlocutores con quien el equipo mantuvo contacto en varias etapas del proyecto.
Ilustración 1 - Estructura organizativa del área de Operaciones.
Gerente de operaciones – Gonzalo González: Gonzalo es Ingeniero de la Universidad de la República. Fue el encargado de realizar la presentación en la feria de proyectos y el principal interesado del lado del cliente. Es una persona relativamente nueva en el área con no más de 5 años, suplantando a una persona que estuvo en su cargo por más de 26 años.
15 Dentro de otras actividades inherentes a su cargo, tiene la responsabilidad de asignar tareas a los empleados que tiene a su cargo y brindar informes con métricas de cumplimiento al Gerente General y Equipo Directivo de la Organización.
De las entrevistas realizadas entre el equipo y Gonzalo surgen conceptos que resultan claves para entender la situación actual y/o el contexto. Se plantea la necesidad de reorganizar su equipo de trabajo con el fin de mejorar el desempeño que realizan día a día y esperando tener como consecuencia el aumento de la productividad del área en su totalidad. Esta problemática radica en que, según sus palabras: “existe mucho papeleo” en el registro y seguimiento de tareas, además de interacciones entre el personal. Por otro lado, informa que han intentado adquirir herramientas informáticas ya desarrolladas en el mercado para ayudarlos en sus actividades, pero éstas no se adaptan a sus necesidades o viceversa.
Supervisor – Nelson Pereyra: Nelson trabaja a la par con otros tres compañeros más en su mismo rol. Su actividad se ejerce en el turno de la tarde con días de descanso rotativos. Está vinculado a Tres Cruces hace más de 20 años.
Entre sus principales actividades, se destaca la responsabilidad en las tareas que le son asignadas, esto involucra su seguimiento y control. Además, es la contraparte directa con los distintos proveedores de servicios tercerizados que dan soporte para cumplir con las tareas, monitoreando y reportando los tiempos de cumplimiento.
Cuenta con planillas en papel donde realiza los registros para llevar adelante sus tareas y cuya información luego es consolidada y transferida a formato digital.
2.1. Estructura
A continuación, se van a enumerar las principales estructuras y conceptos que el área de Operaciones utiliza y, por consiguiente, el equipo debió familiarizarse a fin de hablar un lenguaje común.
2.1.1. Recorridos
Los recorridos son revisiones realizadas a pie que comprenden todo espacio de las instalaciones de Tres Cruces. Tienen como objetivo la identificación de problemas de mantenimiento a resolver. Estos problemas son de desperfectos de todo el predio,
16 como pueden ser: rupturas en escaleras mecánicas, cisternas rotas en los baños, vidrios rotos, ascensores trancados, baldosas rotas (internas o externas), cartelería rota o apagada, aires acondicionados en mal funcionamiento.
Estos recorridos se realizan semanalmente por el gerente y supervisores del área. A medida que se van encontrando con problemas a resolver, se anotan en una planilla en papel que luego son ingresadas en un archivo Excel. De esta manera, se detectan 2 canales para el registro de un recorrido: papel y Excel.
Una vez finalizado, toda la información recabada es analizada y priorizada para derivar el recorrido en la creación de una actividad.
En ocasiones, si surge alguna ruptura en los días que no se hacen recorridos, pueden ser reportados vía mail por algún integrante de otro departamento, dando agilidad a la solución en casos de urgencias.
Cabe destacar que los problemas detectados por personal de otras áreas y enviados por mail a Operaciones pasan a ser directamente una Actividad, debido a que no hay recorrido asociado.
2.1.2. Actividades
Las actividades son incidentes o tareas que realizan los empleados del área, pueden surgir de los recorridos o no (como en el caso que se mencionó cuando es reportado por mail). La particularidad que tienen es que es una especificación de tareas que se llevan a cabo para resolver el problema detectado en un recorrido.
Un recorrido puede generar más de una actividad cuando se detectan varios problemas a resolver.
Suponiendo que en un recorrido se identificaron los siguientes problemas: una canilla rota en el baño de mujeres, un ascensor trancado en el segundo piso, una televisión rota en la plaza de comidas y una lámpara rota en la entrada del Shopping, esto genera al menos cuatro Actividades, una para cada problema, siendo único el recorrido asociado.
17 El área tiene esta operativa debido a que les resulta productivo tener un registro que indique de dónde, cómo y cuándo se generó una Actividad.
Las Actividades también son registradas en papel y luego copiadas a Excel, además de las que se originan desde los mails. Surgen así los tres canales de registro de Actividades: papel, Excel y mail.
Una vez se definieron las actividades a llevar a cabo, son priorizadas y asignadas a los responsables (supervisores) quienes se encargan de repartir esas tareas entre los empleados que las ejecutan.
Las actividades son planificadas en diferentes plazos según su urgencia, pero no suelen exceder un mes. Aquellas cuyos tiempos de resolución requieren más de un mes, se convierten en Objetivos o Proyectos que se explicarán en el siguiente capítulo.
2.1.3. Proyectos
Los proyectos pueden ser de dos tipos: de arreglos o mejoras, ambos se planifican a mediano y largo plazo, a diferencia de las Actividades que no pueden superar el mes de finalización. Los proyectos necesitan ser avalados con el capital que provee el equipo directivo del Shopping, es decir, se plantean los proyectos de ambos tipos y se solicita el capital necesario. Una vez aprobado se convierte en Objetivo que se explicará en el siguiente capítulo de este documento.
Un Proyecto de arreglo es una incidencia a resolver, detectada en los Recorridos y cuya complejidad es de tal magnitud que requiere dividirse en varias tareas. Estas tareas son definidas y registradas antes de dar comienzo a su ejecución, de manera que una vez iniciadas puedan ser asignadas a sus responsables.
Un ejemplo de Proyecto de este tipo es la reparación de pantallas led exteriores para publicidad, cuyas tareas necesarias son: solicitud de alquiler de andamio a empresa externa, contratación de personal externo para la ejecución de la tarea, solicitud de compra de nueva pantalla en caso de ser necesario.
Por otra parte, los Proyectos de mejoras, son originados con la finalidad de realizar tareas que no tengan que ver con arreglos, pero sí que generen un cambio productivo para el Shopping. Estas mejoras también son presentadas al equipo directivo del
18 Shopping Tres Cruces por el gerente de operaciones, donde se analizan y evalúan las posibilidades de asignar capital para su ejecución. En el caso de ser aprobados también se convierte en Objetivo y derivan en la creación de sus actividades asociadas. Estas actividades son priorizadas y asignadas a los empleados. No siempre que se identifica una potencial mejora es inmediata su implementación, es por esto que suelen registrarse con el fin de mantener un orden de precedencia de mejoras.
Un ejemplo de este tipo de proyecto es la adquisición de un termógrafo y sus tareas relacionadas pueden ser: solicitud de presupuesto, capacitación al personal que los manipulará e instalación.
Ambos tipos son registrados también en papel y luego copiados a un Excel, en algunos casos esta información se pierde debido a que pasa cierto tiempo donde no están siendo trabajados y se traspapela con otros archivos, lo que dificulta su seguimiento.
En esta instancia se identifican 2 canales de registro: papel y Excel.
2.1.4. Objetivos
Los Objetivos también se planifican a mediano o largo plazo y representan Proyectos ya autorizados para ejecutarse, por lo tanto, cuenta con la aprobación del capital y pueden ser de arreglos o mejoras. Además, pueden estar asociados a otros departamentos y se registran cuando ya es efectiva su implementación.
Un Objetivo de arreglo al igual que un Proyecto de arreglo, es la resolución de un problema que deriva en varias tareas con una duración mayor a un mes. La duración de las tareas impacta en el tiempo de ejecución y muchas veces no depende únicamente del área de Operaciones, sino que involucra otras áreas como el departamento de Compras, Administración y Finanzas, las autorizaciones correspondientes y la respuesta de los proveedores.
Un ejemplo de ello es el arreglo de un cartel de entrada hacia el exterior del Shopping, si el problema es una luminaria de una letra que no funciona esto genera varias tareas, como: solicitar un andamio, contratar a la empresa externa que se encarga de este tipo de arreglos y solicitar la compra de las luces. Las tareas de los objetivos también son asignadas a diferentes empleados.
19 Los objetivos se registran en papel y luego son copiados a Excel, generando así 2 canales de registro: papel y Excel.
20
3. Problema
En este capítulo se presenta el problema a resolver, explicando la necesidad del cliente y las diferentes casuísticas que maneja en la actualidad.
3.1. Explicación
Como se explicó en el capítulo 3 el registro de los recorridos, actividades, objetivos y proyectos se realizan en varios formatos para comunicarlo a todos los integrantes del área, que tiene como objetivo analizarlos, priorizarlos y asignarlos a los empleados según la disponibilidad. Los formatos que se manejan actualmente son: en papel, en archivos Excel y vía mail.
A medida que se van asignando las tareas y avanzando en ellas se deben actualizar estos registros en todos sus formatos, de manera de poder organizar el trabajo diario.
En este punto es donde surge el problema presentado por el cliente, que se define de la siguiente manera:
El registro del trabajo de Operaciones se realiza en varios formatos, que no todos son actualizados dinámicamente y no se puede saber el estado de cada tarea, como tampoco conocer la disponibilidad de cada empleado. Es decir, puede que se finalice una tarea y la misma sea actualizada en el registro en papel, pero no es actualizada en el archivo Excel, incluso ocurre que no esté registrada en el mail. Se ha detectado que, en algunos casos, el estado de la tarea no se actualiza en ninguno de los formatos.
Además, este problema trae consecuencias que generan otras dificultades, tales como:
En las reuniones semanales que mencionamos en el capítulo anterior, los interesados presentan sus archivos de registros de tareas y al no estar todos actualizados se generan dificultades de planificación y seguimiento de las mismas.
Por otra parte, resulta difícil poder identificar aquellos empleados que están disponibles para poder asignarles nuevas tareas.
21
Otro problema que se genera es que no se pueden estimar los tiempos que llevan las tareas similares y, por consiguiente, no se puede hacer una planificación certera a futuro.
Se constata, además, que no es posible hacer una medición del trabajo.
Por otra parte, se pierde tiempo en buscar el historial de tareas realizadas por usuario, así como identificar cuáles están asignadas en el momento de su búsqueda. Sumado el tiempo que hoy lleva la consolidación de la información.
Se identifica también la pérdida de tiempo generada al actualizar todos los archivos que utiliza el área.
Se concluye con la información citada en los párrafos anteriores que el proceso actual de carga de información, actualización, búsqueda, estimación y planificación consta de una serie de pasos que se pueden disminuir con la propuesta de solución que se plantea en el siguiente capítulo. Donde se agrega el diagrama de flujo de cada proceso actual y su comparación con los nuevos procesos de la solución.
3.2. Necesidad usuario final
Se define como usuario final a todo empleado que ejecuta las tareas que le son asignadas.
La necesidad de este tipo de usuario es visualizar un listado con todas las tareas que le son asignadas, en orden de prioridad, siendo las más urgentes las que se muestren en primer lugar; y preferentemente aquellas que no hayan sido finalizadas. De esta manera puede organizar su trabajo diario y saber cuáles están pendientes para ser tomadas a medida que las vaya finalizando.
3.3. Necesidad usuario gestión
Se define como usuario de gestión a el / los empleados que se encargan de asignar las tareas, priorizarlas, hacerles seguimiento y control. Estos usuarios son los que tienen el rol de supervisor y gerente del área en la organización.
22 Este tipo de usuario tiene la necesidad de visualizar un listado de todas las tareas asignadas a todos los usuarios, en orden de prioridad, pudiendo filtrar por estado de tarea y responsable.
Además, son los encargados de crear, asignar, modificar y eliminar los registros.
Se desea contar también con la visualización de las fechas de inicio y fin de cada actividad, objetivo y proyecto, que serán datos de insumo a la hora de estimar y planificar los trabajos a futuro, así como también poder hacer la medición del trabajo.
23
4. Solución
En este capítulo se presenta la solución propuesta por el equipo para el cliente y el alcance del proyecto. También se especifica lo que quedo fuera de alcance y los diferentes entregables.
4.1. Propuesta del equipo
Para dar solución al problema, se propone unificar toda la información en un sistema interno de gestión de incidentes. Este sistema tendrá el fin de mejorar los procesos mencionados de forma de mantener un único formato, único tipo de datos y facilitar la carga de la misma.
La herramienta va a almacenar y dar visibilidad a cuatro tipos de datos principales:
Recorridos, Actividades, Objetivos y Proyectos con sus respectivas. También se manejarán datos del tipo Parámetros que sirven para la carga de: Estados, Prioridad, Ubicación y Trayectos.
Las tareas surgidas de las actividades, objetivos y proyectos podrán ser asignadas a uno o más responsables, permitiendo: cargar información sobre las mismas, medir el tiempo de trabajo de cada una y priorizarlas.
La aplicación contará con diferentes perfiles de usuarios según su rol en el área y las funcionalidades que pueden ejercer sobre el sistema.
A continuación, en la ilustración 2 se muestra el proceso de carga actual para los recorridos y en la ilustración 3 cómo se redefine aplicando la solución.
24 Ilustración 2 - Diagrama de proceso de recorridos antes.
Ilustración 3 - Diagrama de procesos de recorridos después.
25 En la ilustración 4 se muestra el proceso actual de las Actividades, antes de aplicar la solución. El proceso modificado aplicando la solución se muestra en la ilustración 5.
Ilustración 4 - Diagrama de procesos de actividades antes.
Ilustración 5 - Diagrama de procesos de actividades después.
Los objetivos y proyectos tienen procesos similares, sólo difieren en los plazos que manejan. En la ilustración 6 se puede observar el proceso actual para los objetivos y proyectos. Por otro lado, en la ilustración 7 se pueden observar los procesos luego de aplicada la solución.
26 Ilustración 6 - Diagrama de procesos de objetivos y proyectos antes.
Ilustración 7 - Diagrama de procesos de objetivos y proyectos después.
27
5. Ingeniería de requerimientos
En el presente capítulo, se explica el proceso de ingeniería de requerimientos. Se detallan y justifican las etapas y se enumeran las necesidades junto con los requerimientos.
5.1. Proceso
El proceso de ingeniería de requerimientos es instanciado al comienzo del proyecto, forma parte de la etapa inicial de análisis y requerimientos donde se relevan y priorizan.
En esta instancia se relevaron los requerimientos principales en base a las necesidades del cliente y orden de importancia. El encargado de definir la prioridad de los módulos a implementar es el gerente del área. Esto se planificó así debido a que es necesario saber a grandes rasgos de qué módulos consta el sistema con el fin de poder organizar el trabajo del equipo, estimar tiempo, planificar fechas de entrega e identificar el alcance al cual el equipo se comprometió a llegar.
El equipo entiende que hacer una especificación de requerimientos desde el momento cero, puede implicar un análisis exhaustivo que, de sufrir cambios en el camino, quedaría sin efecto, pero también se tuvo en cuenta que para poder cumplir un compromiso del alcance del producto es inevitable saber, al menos cuáles son las principales necesidades de los usuarios del sistema y poder así definir los pasos a seguir conforme se va avanzando. Es por esto que en este análisis se decidió no hacer una especificación detallada, sino que se definieron las principales estructuras y orden de prioridad. La especificación de requerimientos en profundidad se hace al comenzar cada iteración.
Para relevar los requerimientos el equipo lo realizó de manera muy cercana con el cliente mediante la técnica de reuniones semanales virtuales. En estas reuniones formales, el equipo se focalizaba en tomar conocimientos y recabar información de las necesidades, restricciones y de los requerimientos funcionales y no funcionales.
Para la especificación de los requerimientos en cada iteración se mantuvieron las mismas técnicas de elicitación inicial, mencionadas anteriormente y se agregó la
28 validación a través del maquetado ilustrativo que representaría la solución; ver Anexo 1.
Se le entregó a Gonzalo una lista de requerimientos para que los priorizara. Este orden o priorización tenía la finalidad de categorizar los requerimientos para alinearse y dar visibilidad de cuáles eran los más importantes, riesgosos o esenciales para que el producto final cumpla con las necesidades esperadas.
5.2. Alcance
De la primera instancia de relevamientos surgen las necesidades principales que abarcan todo el ciclo del proyecto, para lo cual se definió en un modo global que el Sistema de Gestión a implementar contará con 4 módulos:
Recorridos
Actividades
Objetivos: con una lista de tareas
Proyectos: con lista de tareas
Cada uno de estos módulos tendrá las siguientes funcionalidades:
Alta
Baja
Modificación
Visualización
Asignación de la actividad, objetivo o proyecto a uno o más empleados
Histórico de asignaciones
Creación y visualización de histórico de comentarios de cada tarea.
Todas estas funcionalidades serán enmarcadas dentro de un control de permisos de usuario ingresado, pudiendo algunos ver solamente los registros asignados a él,
29 mientras que otros tendrán el acceso total. De manera que algunos podrán crear nuevos registros, modificarlos o eliminarlos, mientras que otros; solamente visualizar.
La definición de los permisos a cada rol será realizada por Gonzalo González, o quien él considere.
En la pantalla de cada módulo se verá el listado correspondiente, con algunos filtros para facilitar las búsquedas donde estarán ordenados según la prioridad ingresada para cada uno y la cantidad de días restantes para su finalización.
Cada iteración finalizada y probada se entrega mediante la actualización de la aplicación, alojada en el servidor de Tres Cruces que se proveyó por el área de TI.
Esta tarea la realiza el equipo de estudiantes y la notificación se realiza mediante un mail con copia a Gonzalo y Nelson.
Luego de actualizada la versión se hace una reunión por Google Meet [1] para mostrar los cambios desarrollados y evacuar eventuales dudas.
5.2.1. Restricciones
Dado que este proyecto es de carácter académico, la fecha de entrega es inamovible siendo el 08 de abril de 2022 y por lo tanto todo cambio que surja en el transcurso del mismo y que genere un alto impacto, será analizado por el equipo teniendo en cuenta el cumplimiento de dicha fecha.
5.3. Fuera de alcance
De común acuerdo entre el equipo y el cliente se definió que queda fuera del alcance de este proyecto los siguientes temas:
El equipo no se encarga de respaldar las bases de datos asociadas al programa una vez finalizado el proyecto.
El equipo no se encarga de respaldar las carpetas de la aplicación luego de la última iteración. Pero sí lo hará durante el transcurso del proyecto, de manera que, de generarse algún error se pueda volver a la versión anterior mientras se corrige, con el fin de mantener disponible el sistema en todo momento. Estas
30 carpetas se respaldan en el servidor del cliente, en las máquinas locales de cada integrante y en la carpeta compartida de Google Drive [2].
Una vez finalizado el proyecto: 8 de abril de 2022, el equipo no se compromete a realizar mantenimiento, ni extensión, ni cambios del producto entregado.
Todos los eventuales requerimientos que se releven para la última iteración se consideran deseables y no forman parte del alcance al que se compromete el equipo, se decidió contemplarlo ya que se podría implementar solamente si sobran días luego de entregada la última iteración.
En todo momento del análisis y relevamiento de requerimientos prevalecen las priorizadas por el usuario en el alcance acordado al comienzo del proyecto, esto quiere decir que si al transcurrir las distintas iteraciones el cliente manifiesta necesidad de implementar funcionalidades que no estén relacionadas con las cuatro principales: recorridos, actividades, objetivos y proyectos; el equipo decidirá en base a los tiempos disponibles e impacto de cambio, si se aceptan o no. Sin perjuicio de ello, se documentan en un archivo que se comparte con el cliente por si le es útil a futuro en caso de que un externo colabore con el mantenimiento o extensión del sistema.
5.4. Entregables
Se acordó con el cliente que al finalizar el proyecto se le entregará la carpeta de la aplicación, el código fuente, un manual de usuario y la base de datos con la configuración inicial de usuarios y perfiles. A continuación, se detalla cómo se realizan estos entregables.
5.4.1. Software
El código fuente del sistema será entregado al cliente, el mismo se genera en una carpeta que queda almacenada dentro del directorio de Genexus, en las computadoras locales de los desarrolladores. Esta carpeta será entregada mediante el envío de un mail, en un archivo tipo .rar, con copia a Gonzalo González y los integrantes del departamento de sistemas de la organización. Además, se dejará copiada también en el servidor del cliente.
31 5.4.2. Ejecutable
En este caso, el ejecutable es la carpeta de aplicación la cual es accedida desde una web. En cada iteración se realiza la actualización de la nueva versión y se envía un mail a los usuarios con el enlace de acceso. Dicho enlace no se modifica hasta la iteración 4 en la cual se implementa la pantalla de inicio de sesión y pasa a ser la pantalla principal de acceso.
Si bien la aplicación se instala en el servidor del cliente, al finalizar el proyecto se comparte la carpeta a través de un mail en un archivo tipo .rar con copia al área de sistemas y al gerente de operaciones.
5.4.3. Archivos
Los archivos que se envían a los interesados son los mencionados en los dos capítulos anteriores, además se comparte una guía para los usuarios, que se detalla a continuación.
5.4.4. Guía de usuarios
Al culminar cada iteración con los requerimientos implementados, además de realizar la demostración en las reuniones virtuales con el cliente, les compartimos vía mail un manual de usuario para que puedan usar como guía para realizar las pruebas. El manual se encuentra en el Anexo 5.
5.5. Requerimientos
A continuación, se enumeran los requerimientos funcionales y no funcionales relevados. Se detallan también los actores identificados para el uso del producto.
En el Anexo 2 se muestran los casos de uso, que, de común acuerdo con el cliente, detallan los principales requerimientos funcionales del producto.
5.5.1. Actores
Gerente: Usuarios con permisos totales sobre el sistema. Entre sus potestades principales se encuentran: ingresar, asignar y realizar el seguimiento detallado de las distintas tareas velando por el cumplimiento de las mismas.
32
Supervisor: Usuarios responsables de dar cumplimiento a la tarea que se le asigna.
Sistema: Es el propio sistema
5.5.2. Requerimientos funcionales RF1 – ABM de recorridos.
Usuario: Gerente.
Descripción: El usuario podrá dar de alta, baja y modificar recorridos realizados generalmente una vez por semana por las instalaciones.
Los principales datos a gestionar son el nombre, fecha de ingreso, usuario que lo ingresa y el trayecto al que corresponde
RF2 – ABM de actividades.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá dar de alta, baja y modificar actividades. Estas actividades son incidentes que requieren atención por parte del personal y que son detectadas generalmente en los recorridos.
Los principales datos a gestionar son la descripción de la actividad, la prioridad, la fecha de ingreso, la fecha de inicio, la fecha de fin estimada, un valor kpi, el estado, el recorrido en que se detectó y la observación general
RF3 – Asignar usuario a actividad.
Usuario: Gerente.
Descripción: El usuario podrá asignar actividades a los usuarios subordinados como son los encargados. Esta actividad o incidente puede ser asignado a más de una persona para su posterior atención y seguimiento.
RF4 – Agregar comentarios a actividades.
Usuario: Gerente – Encargado.
33 Descripción: El usuario podrá agregar comentarios a las distintas actividades que tiene asignada.
RF5 – Evento automático en actividades.
Usuario: Sistema.
Descripción: El sistema generará un evento automático al asignar usuarios con la finalidad de mantener el historial de asignaciones
RF6 – Evento automático en actividades.
Usuario: Sistema.
Descripción: El sistema generará un evento automático al modificar el estado de la actividad con la finalidad de mantener el historial de los estados por el cual transcurrió la actividad
RF7 – Visualizar detalle de actividades.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá visualizar todos los datos de la actividad, incluyendo los movimientos y eventos asociados como lo son, el historial de asignaciones al personal y los distintos estados por los cuales ha transcurrido.
RF8 – Panel de control actividades.
Usuario: Gerente.
Descripción: El usuario podrá visualizar a través de un listado, todas las actividades disponibles para asignar. Las que ya están asignadas, se le mostrará el nombre persona.
RF9 – Búsqueda de actividades.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá buscar actividades filtrando por el campo nombre.
34 RF10 – Ordenamiento de listado de actividades.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá ordenar ascendente y descendente el listado por los campos disponibles.
RF11 – Agenda diaria de actividades.
Usuario: Encargado.
Descripción: El usuario contará con un listado de sus actividades asignadas. Este listado se mostrará por defecto ordenado por la fecha de entrega más cercana y con la priorización asignada
RF12 – ABM de proyectos.
Usuario: Gerente.
Descripción: El usuario podrá dar de alta, baja y modificar proyectos.
Los principales datos para gestionar son la descripción del proyecto, el estado en que se encuentra, fecha de inicio, fecha de fin y un comentario general del mismo.
RF13 – ABM de tareas a proyectos Usuario: Gerente – Supervisor.
Descripción: El usuario podrá dar de alta, baja y modificar tareas asociadas a proyectos.
Los principales datos para gestionar son la descripción, fecha de inicio, fecha de fin estimada y fecha de fin real.
RF14 – Asignar usuarios a tareas de proyectos Usuario: Gerente
35 Descripción: El usuario podrá asignar tareas de proyectos a los usuarios subordinados como son los encargados o a él mismo. Estas tareas pueden ser asignadas a más de una persona para su posterior atención y seguimiento.
RF15 – Agregar comentarios a proyectos Usuario: Gerente – Supervisor.
Descripción: El usuario podrá agregar comentarios adicionales en el proyecto. Estos comentarios serán anexados a la bitácora del proyecto
RF16 – Evento automático en proyectos.
Usuario: Sistema.
Descripción: El sistema generará eventos automáticos al asignar usuarios. Este evento se anexará a la bitácora de proyecto
RF17 – Evento automático en proyectos.
Usuario: Sistema.
Descripción: El sistema generará eventos automáticos al modificar el estado del proyecto. Este evento se anexará a la bitácora de proyecto
RF18 – Visualizar bitácora de proyectos.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá visualizar todos los datos relacionados al proyecto como también los eventos automáticos asociados.
RF19 – Panel de control de proyectos Usuario: Gerente.
Descripción: El usuario podrá visualizar todos los proyectos y sus tareas contando con un acceso rápido para poder asignar tareas y agregar comentarios.
RF20 – Búsqueda de proyectos.
36 Usuario: Gerente – Supervisor.
Descripción: El usuario podrá buscar proyectos filtrando por el campo nombre.
RF21– Ordenamiento de listado de proyectos.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá ordenar ascendente y descendente el listado de proyectos por los campos disponibles.
RF22 – Agenda diaria de tareas de proyectos.
Usuario: Encargado.
Descripción: El usuario contará con un listado de las tareas de proyectos que tiene asignada. Este listado se mostrará por defecto ordenado por prioridad y fecha más próxima.
RF23 – ABM de objetivos.
Usuario: Gerente.
Descripción: El usuario podrá dar de alta, baja y modificar objetivos.
Los principales datos para gestionar son la descripción del objetivo, el estado en que se encuentra, fecha de inicio, fecha de fin, un comentario general del mismo y un campo número de uso interno.
RF24 – ABM de tareas de objetivos.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá dar de alta, baja y modificar tareas asociadas a objetivos.
Los principales datos para gestionar son la descripción, fecha de inicio, fecha de fin estimada y fecha de fin real.
RF25 – Asignar usuarios a tareas de objetivos.
37 Usuario: Gerente.
Descripción: El usuario podrá asignar tareas de objetivos a los usuarios subordinados como son los encargados o a él mismo. Estas tareas pueden ser asignadas a más de una persona para su posterior atención y seguimiento.
RF26 – Agregar comentarios a objetivos.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá agregar comentarios adicionales al objetivo. Estos comentarios serán anexados a la bitácora del objetivo
RF27 – Evento automático en objetivos.
Usuario: Sistema.
Descripción: El sistema generará eventos automáticos al asignar usuarios. Este evento se anexará a la bitácora de objetivo
RF28 – Evento automático en objetivos.
Usuario: Sistema.
Descripción: El sistema generará eventos automáticos al modificar el estado del objetivo. Este evento se anexará a la bitácora de objetivo
RF29 – Visualizar bitácora de objetivo.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá visualizar todos los datos relacionados al objetivo como también los eventos automáticos asociados.
RF30 – Panel de control objetivos.
Usuario: Gerente.
Descripción: El usuario podrá visualizar todos los objetivos y sus tareas contando con accesos rápidos para asignar tareas y agregar comentarios.
38 RF31 – Búsqueda de objetivo.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá buscar objetivos filtrando por el campo nombre.
RF32 – Ordenamiento de listado de objetivo.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá ordenar ascendente y descendente el listado de objetivos por los campos disponibles.
RF33 – Agenda diaria de tareas de objetivos.
Usuario: Supervisor.
Descripción: El usuario contará con un listado de las tareas de objetivos que tiene asignada. Este listado se mostrará por defecto ordenado por prioridad y fecha más próxima.
RF34 – ABM de estados Usuario: Gerente.
Descripción: El usuario podrá dar de alta, baja y modificar estados. Estos estados ser podrás asociar a las actividades, proyectos y objetivos.
RF35 – ABM de prioridades Usuario: Gerente.
Descripción: El usuario podrá dar de alta, baja y modificar prioridades las cuales se asociaron a las actividades, tares de proyectos y tareas de objetivos.
RF36 – ABM de usuarios.
Usuario: Gerente.
Descripción: El usuario podrá dar de alta, baja y modificar usuarios.
39 Los principales datos a gestionar son el nombre, el email, un número de teléfono, la dirección y un rol.
RF37 – ABM de trayectos Usuario: Gerente.
Descripción: El usuario podrá dar de alta, baja y modificar trayectos. Estos corresponden a secciones de las instalaciones.
RF38 – ABM de roles Usuario: Gerente.
Descripción: El usuario podrá dar de alta, baja y modificar roles. Estos roles se asignarán a cada usuario para pueda acceder al sistema y define su esquema de seguridad.
RF39 – ABM de ubicaciones Usuario: Gerente.
Descripción: El usuario podrá dar de alta, baja y modificar ubicaciones.
RF40– Iniciar sesión en el sistema.
Usuario: Gerente – Supervisor.
Descripción: El usuario podrá Iniciar sesión en el sistema con un usuario y contraseña.
RF41 – Cerrar sesión.
Usuario: Gerente - Supervisor
Descripción: Permitir al usuario cerrar sesión en el dispositivo.
5.5.3. Requerimientos no funcionales
A continuación, se presentan los requerimientos no funcionales con su respectivo atributo de calidad asociado y los mecanismos utilizados para cumplir con estos atributos.
40 En el capítulo 12.3.6 se presentará los métodos de medición y los resultados para cada uno de ellos.
RNF1 – Las interfaces del sistema deben de ser fáciles de usar.
Atributo de calidad: Usabilidad.
Método de medición: Se define y se avala por parte de cliente que fácil de usar es ingresar una actividad, una tarea de proyecto o una tarea de objetivo en no más de 5 pasos
RNF2 – Las interfaces del sistema deben de ser intuitivas.
Atributo de calidad: Usabilidad.
Método de medición: Se utiliza la técnica de observación. Luego de cada iteración o entregable se visita al usuario y se lo observa operando el sistema.
Se evaluará principalmente algunas de las heurísticas de Nielsen [3] como son:
“Utilizar el mismo lenguaje que el usuario” y “Consistencia y estándares”
RNF3 - Ampliación adaptable para que se pueda usar en un navegador web y en un navegador de dispositivo móvil.
Atributo de calidad: Portabilidad.
Método de medición: Se validará que el producto se ajuste en su diseño para un navegador de internet como como para dispositivos móviles
RNF4 - El sistema deberá permitir el acceso de cuentas de usuario ya creados en la plataforma.
Atributo de calidad: Seguridad.
Método de medición: Se crearon usuarios con diferentes permisos
41 5.5.4. Requerimientos fuera de alcance
A continuación, se presenta un requerimiento o deseable que dado los tiempos y el momento en el transcurso del proyecto donde surgió el mismo, el equipo junto con el cliente resolvió documentarlo, pero dejarlo como fuera de alcance.
RFA1 – Subir fotos desde dispositivos móviles.
Se desea que se pueda subir fotos y asociarlas a las actividades o tareas desde dispositivos móviles.
42
6. Arquitectura
En este capítulo se presenta la arquitectura del sistema. Se divide en dos grandes tipos: arquitectura interna de Genexus y diseño de la aplicación.
6.1. Introducción
La plataforma de desarrollo utilizada en la implementación de este sistema tiene una estructura interna que permite generar aplicaciones del tipo cliente - servidor y resulta ser bastante rígida en su diseño, es por esto que el diseño que creó el equipo corresponde al propio de la aplicación definiendo particularmente la estructura de la base de datos, estándares de programación, limpieza de código y nombres nemotécnicos que se detallan a continuación.
6.2. Atributos de calidad 6.2.1. Usabilidad
Para definir la usabilidad se enmarcó un diseño basado en las heurísticas de Nielsen y que fueron medidas de manera presencial cuando el cliente probaba la aplicación.
Para ello, el equipo armó una lista con dichos aspectos que al repasar uno a uno en el seguimiento con el cliente si se cumplía se consideraba logrado este aspecto de calidad. Estas instancias presenciales para determinar la usabilidad se realizaron cada vez que se finalizó y actualizó una iteración.
6.2.2. Portabilidad
La aplicación desarrollada es de carácter responsivo para poder ser accedida desde un celular y computadora, pero está optimizada para esta última.
No se pudo probar accediendo directamente desde un celular, debido a que el área de sistemas debía configurar las VPNs en los celulares de los usuarios, para poder acceder y no lo lograron en el tiempo solicitado. Sin embargo, se utilizó la herramienta web que brinda el navegador Google Chrome [4], la que permite modificar los tamaños de pantalla. De esta forma se pudo simular el tamaño de pantalla de un celular promedio, pudiendo probar las funcionalidades y también la navegabilidad en las mismas.
43 6.2.3. Seguridad
Para contemplar la seguridad de acceso al sistema y navegabilidad todos los objetos del programa que representan pantallas fueron encapsulados en un módulo de seguridad que consta de la obtención del usuario logueado (usuario_id), buscar el perfil asociado al mismo y en el perfil buscar la pantalla a la que está intentando acceder, si existe el registro significa que tiene acceso, en este caso se busca además las funcionalidades que puede ver y se muestran solo las correspondientes. Si no existe el registro, significa que a esa pantalla no puede acceder y por lo tanto se lo redirige a otra de “no autorizado” indicando tal situación.
Además, las sesiones de usuario están configuradas para que permanezcan activas por 30 minutos, este tiempo es el que definió como razonable el cliente.
Por otra parte, el equipo de sistemas decidió que la aplicación sea accedida únicamente dentro de la red de la organización por tratarse de un sistema de gestión interno. Esto quiere decir que no se contrató ningún dominio para hacer el acceso público.
6.3. Infraestructura
En cuanto a las tecnologías de infraestructura se utilizó un servidor provisto por el área de tecnologías de la información de la empresa Tres Cruces. El equipo contó con acceso al mismo a través de una vpn provista por el área. En dicho servidor se instaló la base de datos y el ejecutable de la aplicación, lo cual se detalla más adelante.
6.4. Tecnologías utilizadas 6.4.1. Genexus
La elección del lenguaje de desarrollo se basó según dos principales factores:
experiencia de los integrantes del equipo y beneficios proporcionados por la herramienta.
Los desarrolladores que conforman el equipo tienen su mayor trayectoria basada en la implementación con este lenguaje de programación, por lo que tienen en su haber el conocimiento de errores para poder solucionarlos, el de la instalación y el de la
44 arquitectura interna de Genexus, así como también el funcionamiento de los objetos necesarios para la programación.
También se tuvo en cuenta que el mayor desafío de este proyecto está en la redefinición estratégica de procesos que hoy lleva a cabo el área, para poder ofrecer una optimización en los tiempos de trabajo, además de la posibilidad de eliminar el uso del papel. Por lo cual, el foco no está en lo técnico sino en la habilidad para lograr que lo antes mencionado resulte exitoso, lo cual también nos ofrece la oportunidad de desarrollarnos profesionalmente en estas tareas, que suelen parecer a veces ajenas a la carrera que cursamos. En este sentido, se utiliza la creación de un sistema como vehículo para lograr el mayor desafío que nos compete.
Por otra parte, Genexus ofrece mayores beneficios en comparación con los lenguajes de programación conocidos por los integrantes, que permite un desarrollo más ágil, pero logrando el mismo producto y con la misma calidad sea cual sea el utilizado.
Pensando a futuro, si el cliente decide contratar a un programador luego de la finalización del proyecto para hacerle mantenimiento al sistema, se encuentra con una industria donde la mayoría de los programadores conocen este lenguaje, y de no ser así, los cursos de Genexus están subidos a la web y pueden ser vistos de manera gratuita. Además, en general se considera como bastante simple de aprender en un corto tiempo como para poder desempeñarse en un sistema de pequeño porte como lo es este. Por último, los tiempos de desarrollo se disminuyen enormemente en comparación con otros lenguajes, debido a las automatizaciones que el mismo provee.
En este sentido, no solo pensamos en lo eficiente que resulta esta característica para llevar a cabo este proyecto, sino también que es un aspecto importante a tener en cuenta a la hora de contratar personas para darle continuidad.
En contraste con los beneficios planteados, las licencias para poder utilizar Genexus son pagas, por lo cual el equipo averiguó los precios de las mismas y se las presentó al cliente para su análisis, destacando que, si bien esto representa un costo fijo anual, también se puede ahorrar en el tiempo que lleva generar una solución que indirectamente también se convierte en dinero. Ver Anexo 3.
45 Estos factores fueron presentados al cliente y fueron aprobados por el gerente del área, quien también lo planteó al de sistemas y en común acuerdo llegaron a esta aceptación.
Cabe destacar que, por tratarse de un proyecto académico, la empresa Artech, posesora de Genexus, nos proveyó de 3 licencias gratuitas durante el período que comprende este proyecto, así como también un espacio en la nube para Genexus Server que será detallado más adelante.
En otro orden, éste es un lenguaje de programación de alto nivel, lo que significa que Genexus compila y genera en otro lenguaje intermedio, generando los archivos correspondientes, según cual se elija y que son necesarios para ejecutar la aplicación, es decir que la aplicación generada va a contener las clases en Java de lo que genera Genexus junto a otros archivos vinculados. Dicho lenguaje es parametrizable entre los siguientes: .NET, ADO.NET, Java y Ruby. El equipo decidió generar en Java debido a que tiene mayor conocimiento en el contenedor de aplicaciones para Java, que será presentado a continuación y también conoce los posibles errores que pueden surgir en este ambiente.
6.4.2. Tomcat
Tomcat es un servidor de aplicaciones que permite publicar aquellas que son generadas en Java y salen por el puerto 8080.
Según el conocimiento de los integrantes del equipo, es el único contendor capaz de publicar las que se generan con este lenguaje, por lo que no hubo mucho análisis en profundidad para evaluar y comparar opciones. Además, como se mencionó anteriormente, el equipo cuenta con experiencia en esta herramienta.
Los archivos de tipo clases de Java y los .js se generan en la carpeta webapp del Tomcat, cuyo nombre también es la de la aplicación. En este directorio también se almacena el archivo que tienen la conexión entre el programa y la base de datos, llamado client.cfg.
46 6.4.3. Genexus Server
Dado que el desarrollo lo realizan de manera local los 3 participantes del equipo, fue necesario utilizar alguna herramienta que permita compartir y versionar el código, a la vez que utilizar un repositorio. La mejor herramienta para hacerlo en aplicaciones Genexus, es el propio repositorio que la empresa ofrece, consta de una dirección web donde se reserva un espacio en la nube, bajo un nombre proveído por la empresa y que también suele ser pago, pero por tratarse de un proyecto académico no tiene costo durante todo el ciclo del proyecto.
Este repositorio no es necesario que el cliente lo solicite si quisiera continuar con el mantenimiento y para eso, contratar personal, ya que no es excluyente para el desarrollo de las aplicaciones, solamente se utiliza en caso de querer compartir el código entre desarrolladores.
6.4.4. SQL Server
El servidor de bases de datos escogido fue Microsoft SQL Server debido a que es el que el equipo considera más fácil de usar, eficiente y con agradable interfaz gráfica.
El manejador de base de datos elegido fue SQL Server Managment Studio.
6.5. Descripción de la arquitectura 6.5.1. Backend
La estructura interna de Genexus, como se puede observar en la siguiente ilustración, define la comunicación entre la aplicación ejecutada por el usuario desde el explorador web de su computadora y el servidor en el que es alojada. Esta información se obtuvo de un documento subido a la web por Genexus [5].
En este caso, implementamos la opción provista por Genexus como Cliente Liviano, que significa que las operaciones ejecutadas en el programa son solicitadas al servidor y no son responsabilidad del cliente. La otra opción se llama Cliente Potente y es cuando éste tiene la potestad de ejecutar dichas operaciones, pero nuestro caso, manejamos la primera.
47 La lógica de esta opción implementada está en el servidor, esto quiere decir que cuando el usuario accede a una pantalla el navegador pide la página correspondiente al servidor, éste prepara la información, incluso obtiene datos de la base de datos de ser necesario, arma la pantalla y la envía al navegador para ser visualizada por el usuario.
Ilustración 8 - Diagrama cliente/servidor Genexus
En cuanto al diseño de la aplicación, uno de los profundos análisis que realizó el equipo fue para la creación de la base de datos tratando de contemplar algunos factores importantes, como son: la eficiencia en los tiempos de solicitud y respuesta de datos, índices para agilizar las búsquedas solicitadas por el usuario, análisis de claves foráneas, nombres nemotécnicos para las tablas y atributos y mantenibilidad a futuro con el fin de generar el menos impacto posible.
Por otra parte, en cuanto a la limpieza de código se siguieron los estándares de “clean code” que refieren a no tener objetos obsoletos, minimizar la cantidad de responsabilidad por cada procedimiento, en todo el sistema se utilizó idioma español, si bien hay una tendencia general a utilizar inglés se optó por nuestro idioma debido a que el personal de sistemas no tiene un nivel tan avanzando en la lengua extranjera y podría generar problemas a la hora de hacerles mantenimiento; además, se quitaron comentarios en el código que se fueron agregando como guía en el desarrollo.
La conexión del sistema a la base de datos se hace mediante una configuración desde Genexus y se relacionó a la instalada en el servidor del cliente, de manera que los
48 archivos que almacenan esta información queden asociados al mismo y no se generen problemas a la hora de actualizar y ejecutar la aplicación.
Los archivos del tipo librerías y .dll se almacenan en el directorio donde se instaló Genexus, llamado Models y en su correspondiente aplicación.
6.5.2. Frontend
En Genexus el diseño de las pantallas se considera practico de implementar y además provee la opción de hacerlas responsivas, cualidad que es necesaria para la solución propuesta.
Para el diseño se trabajó sobre un tema definido generando clases específicas para cada tipo de objeto, esto permitió una rápida integración entre el desarrollo de backend con el de frontend. Nos basamos en un color neutro como el negro para el menú y los botones, mantuvimos el logo de la empresa y colores estándares para el resto de los íconos.
Se utilizaron algunos controles de usuario que se agregaron como extensiones en Genexus, los mismos sirvieron para poder cumplir con las especificaciones necesarias de interfaz.
Todos los archivos correspondientes del frontend se almacenan en la webapp del Tomcat como se mencionó anteriormente.
6.5.3. Base de datos
Se utilizó Microsoft SQL Managment Studio como manejador de base de datos, a través de esta herramienta el equipo podía acceder a la misma y visualizar la estructura.
Una de las ventajas de Genexus es que cuenta con la opción de vincular el servidor de base de datos para la generación automática de los impactos correspondientes según el desarrollo.
Lo que se crea como Transacciones en Genexus son lo que representan una tabla en la base de datos y que al compilar impacta directamente en el esquema de la base
49 previamente configurada. También genera el archivo de conexión entre la base y el programa, con los datos encriptados para ofrecer mayor seguridad.
Por otro lado, en el desarrollo con Genexus no se manejan clases del tipo “Sistema”
o “Interfaz” como suele hacerse con Java o .NET, dado que la lógica del sistema se implementa en los objetos “Procedimiento” de esta plataforma. En las Transacciones solo se implementan funcionalidades que tienen que ver con el impacto en la base de datos, como atributos, claves primarias y foráneas y obtención del Id y datos inferidos al entrar a un registro en particular desde la pantalla del cliente. Es por esto que lo que comúnmente se conoce como “Diagrama de Clases” en Java, en Genexus coincide con el diagrama de la base de datos.
La ilustración 9 muestra el diagrama de la base de datos, en el Anexo 4 se expanden para más detalles.
50 Ilustración 9 - Diagrama de la estructura de la base de datos.
51
7. Gestión de la configuración
En este capítulo se presenta la gestión de configuración del software detallando el proceso de instalación y sus elementos relacionados.
7.1. Elementos de la configuración
Los elementos necesarios para la configuración del software en el servidor del cliente son:
Software: se compone del código fuente, carpeta de aplicación y la base de datos utilizada en el sistema.
Documentación: se compone de todos los documentos creados y utilizados durante el transcurso del proyecto y que concluyen en este documento final.
7.2. Gestión de la configuración del software
Como se mencionó en el capítulo de herramientas, el equipo utilizó Genexus Server como repositorio y versionado, alojado en una instancia en la nube. Esto permitió compartir el código entre todos los integrantes.
Para ello, desde la plataforma Genexus se inicia la opción de esta herramienta, el programador que realiza un cambio y prueba que haya quedado bien, lo sube mediante la opción Commit y los programadores que deseen bajarlo en su computadora local, lo hacen mediante la opción Update.
Además, el equipo llevó a cabo dos buenas prácticas que se definió como antes de empezar a implementar algún cambio, debía realizar un Update. Esto evita que, si dos programadores han trabajado en un mismo objeto, no se pierda ninguno de los cambios. La siguiente es que no puede haber simultáneamente más de un programador trabajando sobre un mismo objeto debido a que Genexus no sabe a quién darle la prioridad a la hora de subirlo y eso genera un conflicto en la herramienta.
Las actualizaciones de las versiones locales, es decir, la aplicación del “localhost” de las computadoras de los programadores, se hace automáticamente cada vez que se realiza un Update y luego se compila, sin tener que copiar archivos a mano. Sin
52 embargo, la actualización de la aplicación en el servidor del cliente se hizo a mano copiando dicha carpeta cada vez que se terminaba y probaba una versión.
Las bases de datos se utilizaron de forma local, por cada programador y también en la del cliente. Se separó esta responsabilidad en la del cliente para evitar generar errores mientras se programaba, contemplando la no pérdida de datos ante una actualización. Luego que el impacto de la base estaba correcto en la computadora local, se apuntaba a la del cliente para actualizarla.
7.3. Gestión de la documentación
Todos los documentos se almacenaron en Google Drive permitiendo su dinamismo y actualización en tiempo real, a la vez que se utilizaron las prestaciones de agregar comentario y/o sugerencias para evitar borrar texto hasta que no sea aprobado por todos los integrantes.
Para esto, se creó una carpeta raíz con el nombre del proyecto y dentro; otras, dependiendo del tipo de documentación para facilitar su búsqueda.