Tabla 11. Sprint Backlog del Sprint 1

Figura 26. Product backlog

4.3.3.1.11. Sprint Backlog

Se seleccionó para el primer sprint las 3 historias con más prioridad según el Product Owner, las cuales suman 39 puntos de estimación. Luego, se procedió a realizar el Sprint Backlog, donde se plasman las tareas específicas que pertenecen a las historias de usuarios que se van a ejecutar en el sprint, trabajando de forma conjunta para lograr los objetivos planteados (Tabla 11).

Tabla 11. Sprint Backlog del Sprint 1

Sprint Backlog Objetivo: Desarrollar la funcionalidad del primer producto mínimo viable correspondiente al inicio de sesión, registro de usuario y creación de contactos.

SPRINT HISTORIA EST CATEGORÍA TAREA EST

1 HU1-Login 13

HU2-Registro 13

HU3-Contactos 13 Diseño

Modelado del diagrama entidad-relación, modelo lógico y físico. Desarrollo Creación de la BD en el motor Oracle XE Desarrollo Crear la conexión de la base de datos con el servidor Payara Desarrollo Creación de la AbstractFacade.java que contenga el CRUD Desarrollo Creación del modelo Usuario.java y de la vista login.xhtml

Desarrollo Elaborar el controlador UserLoginController.java para la conexión entre el modelo y la vista, además de verificar que el usuario se encuentre registrado en la BD

Tester

Pruebas unitarias de la clase mediante JUnit Desarrollo Creación de la interfaz Serializable en el modelo Usuario.java, donde se encuentran los campos requeridos para el registro del usuario. Desarrollo Creación de la vista registro registro.xhtml para interpretar los datos del Desarrollo Conexión del controlador UserLoginController.java con la vista registro.xhtml para que los datos llenados sean enviados a la BD. Desarrollo Creación del método al crear la cuenta. create para mostrar un mensaje de confirmación 2 2 2 2 2

2

1 2

3

3

3

Desarrollo Creación del trigger TGUSUARIOSBEFORE la tabla Usuarios de la BD para prevenir errores en 2

Desarrollo Creación del modelo Contactos.java con la interfaz Serializable. Desarrollo Elaborar la vista contactos-form.xhtml en la cuenta de la persona logueada. para la creación del contacto

2 2 Desarrollo Elaborar la vista contactos-edit.xhtml para la edición de los contactos. 2 Desarrollo Elaborar las vistas contacto.xhtml registrados en la cuenta. para la vista de todos los contactos 2 Desarrollo Creación del método create en el controlador ContactoController.java y el enlace con la vista contacto.xhtml Desarrollo Creación de una secuencia valores únicos SEQCONCODIGO para la generación de 3

1

Desarrollo Creación del trigger TGUCONTACTOSBEFORE para prevenir errores en la tabla contactos de la BD 1

Nota: Elaboración propia. HU: Historia de usuario.

4.3.3.2. Reuniones diarias del Sprint 1 –Daily Scrum

Son reuniones informales donde se reunió el equipo de trabajo de 10 a 15 minutos antes del inicio de la jornada para describir avances, planeación diaria, novedades o inconvenientes en relación a las tareas a realizar en dicha jornada. Las reuniones diarias permitieron evaluar el proceso del sprint.

Para visualizar las actividades realizadas se utilizó Jira que es un software de gestión de proyectos para medir el rendimiento y la creación de informes. Jira permite trabajar con el marco Scrum que promueve la toma de decisiones de manera rápida a través de la planificación y supervisión de las actividades por hacer, en curso y listas.

4.3.3.2.1. Historia de usuario 1: Login

Las descripciones de las historias de usuario se encuentran en el Anexo VII, en la parte de diseño se realizó el diagrama entidad-relación para el primer sprint, se procedió con el modelo lógico y finalmente el modelo físico donde se representa a los objetos de datos relacionales (tablas, columnas, claves principales y claves externas) y sus relaciones como se observa en la figura 27.

Figura 27. Modelo físico para el sprint 1

Para crear la historia 1, se instaló Oracle XE que es el motor de base de datos, luego se configuró el Payara Server Community (servidor de aplicaciones de código abierto derivado de GlassFish Server Open Source Edition). La conexión de la base de datos con el servidor Payara requirió el driver de Oracle XE que es ojdbc8-12.2.0.1 en la ruta C:\payara5\glassfish\domains\domain1\lib\ext como se muestra en la figura 28.

Figura 28. Drive ojdbc8 para conexión de la base de datos con el servidor Payara

Oracle XE y los servidores web Java como Payara, Glassfish, Tomcat, JBoss, Weblogic utilizan el puerto 8080, por ese motivo se cambió el puerto de listener de los clientes modificando el archivo domian.xml que se encuentra en la ruta C:\payara5\glassfish\domains\domain1\config, luego se cambió el listener al puerto 7777 y el LISTENER_PORT del system de 28080 a 27777 como se observa en la figura 29 y 30, respectivamente.

Figura 29. Cambio de puerto del servidor Payara Figura 30. Cambio de puerto LISTENER_PORT del system

Para iniciar el servidor Payara se abrió el archivo asadmin en la ruta C:\payara5\bin, una vez abierta la consola se escribió y ejecutó el comando start-domain y stop-domain para iniciar el servidor y apagarlo respectivamente, como se muestra en la figura 31.

Figura 31. Activar servidor Payara

El framework de persistencia que se ocupó es el JPA que permitió trabajar con entidades persistentes conectadas a una base de datos. El fichero de configuración JPA es persistence.xml, donde la unidad de persistencia (PU) es inclusivaPU de tipo JTA, es decir que la PU se encarga de administrar las transacciones del lado del servidor aislando la mayor parte al programador de abrir o cerrar las transacciones, para ello se enlazó la conexión Pool JDBC con InclusivaDS, como se muestra en la figura 32.

Figura 32. Fichero de configuración JPA persistence.xml

La clase UsuariosFacade.java permite interactuar varios subsistemas mediante una única interfaz como se muestra en la figura 33. Esta a su vez está enlazada a la clase AbstractFacade.java que es una clase abstracta que contiene lo necesario para el CRUD

(Create, Read, Update and Delete) permite crear, leer, actualizar y borrar los registros de la base de datos (Figura 34).

Figura 33. Clase UsuarioFacade.java Figura 34. Clase AbastractFacade.java

El controlador responde a las interacciones que hace el usuario y realiza las peticiones al modelo para luego pasarlos a la vista. Se creó el controlador UserLoginController.java para la conexión entre el modelo usuario.java y la vista login.xhtml, validando la información de usuario y clave ingresadas con la base de datos, permitiendo el ingreso a la aplicación si los datos son correctos, caso contrario saldrá un mensaje de “Credenciales incorrectas”. Se agregó la librería ScryptUtil que permite chequear a un usuario para verificar si su clave está o no encriptada. Es decir, si una clave es igual a la registrada en la base de datos permite el ingreso. Además, se obliga el cambio de clave para poderla encriptar, como se muestra en la figura 35.

El software JUnit es un framework para realizar y automatizar las pruebas de aplicaciones en Java. Las pruebas unitarias en JUnit se realizaron para la detección de errores, permitiendo aumentar la fiabilidad del software, a la vez implica el seguimiento de buenas prácticas. En la figura 36 se observan las pruebas unitarias del Login, dando un porcentaje de 100% analizado sin errores.

Figura 35. Controlador UserLoginController.java Figura 36. Pruebas Unitarias del Login en JUnits4

4.3.3.2.2. Historia de usuario 2: Registro

El modelo utilizado para el registro de usuario es el usuario.java creado con anterioridad, ahora con una interfaz Serializable, donde se encuentran los campos para el registro del usuario como el usuusuario, usuclave, usunombres, usunumcelular, usuaceptaterminos, usufotoperfil para el id del usuario registrado, la clave para la cuenta, nombres, número de celular, aceptación de términos y foto de perfil respectivamente, como se observa en la figura 37.

Dentro de la vista registro.xhtml se observa los parámetros: usuario, clave, nombres, correo y celular que se deben ingresar para poder registrar un usuario a la aplicación, además se solicita estar de acuerdo con los términos y condiciones para la creación de la cuenta. Adicional, se muestra un mensaje cuando un campo no es llenado y es requerido (Figura 38).

Figura 37. Creación de la interfaz Serializable para el registro del usuario Figura 38. Parámetros para el registro del usuario

Para el registro de nuevos usuarios se realizó la comunicación entre el controlador UserLoginController.java con la vista registro.xhtml, se utilizó try-catch para no presentar errores en la pantalla del cliente, hasta el momento no está creado el usuario en la base de datos, solo se creó un objeto que deberá ser llenado y después enviado a la base de datos (Figura 39).

Figura 39. Conexión del controlador con el registro.xhtml

Dentro del controlador UserLoginController.java se realizó el método public void create que permite mostrar un mensaje de confirmación “Usuario creado con éxito” una vez creada la cuenta del usuario, para luego direccionar a la vista login.xhtml que corresponde al inicio de sesión, como se observa en la figura 40.

Figura 40. Creación de usuario exitoso y direccionamiento a la vista login.xhtml

El trigger se ejecuta cuando sucede un evento en las tablas a las que se encuentra asociado, almacenando un dato por defecto para prevenir errores en la base de datos al

momento de modificar valores, sincronizar tablas, etc. Para ello se creó uno llamado TGUSUARIOSBEFORE para definir por defecto el rol del usuario y país en caso de no ser seleccionado al momento de realizar el registro del usuario (Figura 41).

Figura 41. Trigger TGUSUARIOBEFORE para país y usuario

4.3.3.2.3. Historia de usuario 3: Contacto

En el modelo contacto.java se creó la clase contactos con la interfaz Serializable, donde se encuentran los campos de la tabla contactos que son el alias (usuusuario), nombre del usuario (conmombres), numero de celular (concelular), además el campo consuapp para verificar si el usuario posee la aplicación, como se muestra en la figura 42.

Figura 42. Creación del modelo Contactos.java con la interfaz Serializable

Se crearon las vistas contacto.xhtml, contacto-edit.xhtml, contacto-form.xhtml para la vista, edición y creación de los mismos respectivamente. En la figura 43, se observa la vista contacto-form.xhtml donde se tiene los parámetros: nombres y celular, en caso de no ingresarlos se cancelará el registro. Además, posee un botón para guardar el contacto y un botón para regresar sin realizar registros.

En la vista contacto-edit.xhtml se puede editar los campos almacenados como nombre del contacto y número de teléfono, campos necesarios al momento de registrar un contacto. Además, se muestra un mensaje de ingreso obligatorio de información en caso de querer dejar vacío uno de los campos, como se observa en la figura 44.

Figura 43. Creación de contacto Figura 44. Edición de contacto registrado

Para la creación de contactos en la cuenta de un usuario se tiene el método create en el controlador ContactoController.java, una vez creado el contacto con éxito se almacena en la base de datos y se direcciona a la vista contacto.xhtml que muestra al usuario el contacto creado (Figura 45).

Figura 45. Creación de contacto y vista del mismo

La secuencia es un objeto que se emplea para la generación de valores únicos-enteros para luego asignarlos a campos numéricos. SEQCONCODIGO permite crear un código incremental desde 1 hasta 99999999 al momento de generar un nuevo contacto, con aumento de 1 en 1 y con un registro inicial de 4, si la tabla contacto llega al máximo valor se bloquea el inicio de la secuencia, además no almacena datos de secuencia en memoria (Figura 46).

Figura 46. Secuencia para la generación de valores únicos

Para generar la secuencia del código primario de la tabla contacto se creó el trigger TGCONCTACTOSBEFORE, se dispara antes de hacer una inserción en la tabla mencionada,

ocurre cuando el código es nulo y se selecciona la siguiente secuencia con la sentencia SEQCONCODIGO.NEXTVAL, se inserta en el nuevo campo CONCODIGO como se muestra en la figura 47.

Figura 47. Trigger para la inserción del campo concodigo

4.3.3.2.4. Gráfico de trabajo pendiente del Sprint 1

En la figura 48, se muestra el trabajo pendiente durante el desarrollo de las tareas del sprint 1, en el tercer día se añadieron dos historias nuevas que generaron un cambio de alcance, además ciertas sub-tareas de las dos primeras historias fueron finalizadas el último día debido a que eran dependientes unas de otras.

Figura 48. Gráfico de Sprint 1

4.3.3.3. Revisión del Sprint 1

Una vez finalizado el primer sprint, se mantuvo una reunión entre el equipo de desarrollo y el Product Owner con la finalidad de revisar las historias de usuarios correspondiente a esta etapa de desarrollo y comprobar el avance de la aplicación móvil. La reunión tuvo una duración de dos horas.

El propósito general fue la retroalimentación de los avances y el trabajo en conjunto de las partes interesadas. Además, se analizó el product backlog para estimar las fechas de las tareas pendientes hasta ese instante. La actividad está evidenciada por medio de las pruebas de aceptación que se realizó con la técnica de caja negra y se aplicó por cada historia de usuario (Anexo VIII).