39. SPRINT #3
Objetivo
Descripción
Material
Procedimiento
- Aplicación Web Responsiva
- Modelo arquitectónico MVC (Modelo Vista Controlador)
- Seguridad de App con sesiones en PHP y encriptación de datos
- Convertir los requisitos funcionales a Historias de Usuario
- Aplicación de la metodología SCRUM para el desarrollo del login y el sistema a desarrollar
- Diseñar y mejorar el mockup que fue realizado en el sprint anterior, validarlo con el cliente
- Configuración de ambiente local con Xampp y git para codificar el login en computadoras locales
- Configuración de ambiente remoto con GitHub y Heroku
- Resultados
- Probar el login final y validar con el cliente final
- Conclusión
- Fuentes bibliográficas
Llevar a cabo una página de nuestro proyecto CB-24H de manera responsiva.
Levara a cabo la investigación y documentación de los diferentes temas relacionados con una aplicación responsiva, así también los modelos y metodologías a ocupar para el desarrollo de una buena página web responsiva.
- Internet
- Software Adobe XD
- Software XAMPP
- Plataforma github
- Una computadora
1. Aplicación Web Responsiva
El Diseño Web Responsivo o “Responsive Web Design” en inglés, es un término que se refiere a la capacidad de que un sitio o diseño web se adapte al tamaño de cualquier dispositivo (smartphone, tablet, laptop o computadora de escritorio). Los elementos web se colocan de forma que se adapten al ancho de cada dispositivo permitiendo una correcta visualización y una mejor experiencia de usuario.
El diseño web responsivo se hace posible gracias a la introducción de las “CSS Media Queries” en las propiedades de los estilos CSS 3. Las “Media Queries” son una serie de órdenes que se incluyen en la hoja de estilos que indica al documento HTML cómo debe comportarse en diferentes resoluciones de pantalla. El sitio Web detecta desde qué clase de dispositivo está accediendo el usuario y muestra la versión más optimizada para ese medio (teléfono inteligente, tableta o pc), reorganizando los elementos de la web e incluso discriminando algunos de ellos. Reconociendo los siguientes puntos:
• Dispositivo: en qué dispositivo se está mostrando en cada momento.
• Tamaño de pantalla: la anchura de su pantalla.
• Navegador: el navegador que está utilizando el visitante.
En base a esto, un sitio web responsivo ajusta automáticamente el contenido. Como resultado, las páginas son claras, comprensibles y agradables de leer desde cualquier dispositivo.
Las principales características de la web responsiva son:
• Ancho adaptable: Adaptación del ancho de la web al ancho del dispositivo que la accede, sin scroll horizontal.
• Reestructuración: Reacomodo de los elementos de la web dependiendo del ancho del dispositivo.
• Elementos: Cambio del aspecto de ciertos elementos de la web, como menú, botones e imágenes.
¿Por qué tener una página responsiva?
• Es recomendada por Google: El algoritmo de Google fue actualizado para dar mayor ranking de búsqueda a las páginas que estén elaboradas con un diseño responsivo.
• Una página, muchos dispositivos: Permite proveer una excelente experiencia al usuario desde cualquier dispositivo y tamaño de pantalla: teléfonos móviles, tabletas, laptops y computadoras de escritorio.
• Más sencillo, más económico: Permite tener un mejor SEO ya que se tienen las mismas URLs (direcciones) para móvil y web. Es más económica de administrar. Permite una descarga más rápida y adecuada en móviles.
2. Modelo arquitectónico MVC (Modelo Vista Controlador)
Es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. Se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo.
• El Modelo que contiene una representación de los datos que maneja el sistema, su lógica de negocio, y sus mecanismos de persistencia.
• La Vista, o interfaz de usuario, que compone la información que se envía al cliente y los mecanismos interacción con éste.
• El Controlador, que actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de información entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno.
El modelo es el responsable de
• Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.
• Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: "Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor".
• Lleva un registro de las vistas y controladores del sistema.
• Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero por lotes que actualiza los datos, un temporizador que desencadena una inserción, etc.).
El controlador es responsable de
• Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
• Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método "Actualizar ()". Una petición al modelo puede ser "Obtener_tiempo_de_entrega ( nueva_orden_de_venta )".
Las vistas son responsables de
• Recibir datos del modelo y los muestra al usuario.
• Tienen un registro de su controlador asociado (normalmente porque además lo instancia).
• Pueden dar el servicio de "Actualización()", para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).
- El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.)
- El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.
- El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
- El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista, aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista.
- La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.
3. Seguridad de App con sesiones en PHP y encriptación de datos.
Aunque con las sesiones y las cookies no se pueda quebrantar la seguridad de la aplicación de forma directa, mediante el robo de sesiones se pueden comprometer las cuentas de los usuarios, y si éstos tienen permisos especiales las consecuencias pueden ser peor de lo esperado. La mayoría de las veces PHP guardará una cookie en el ordenador del cliente llamado PHPSESSID (puede cambiarse al nombre que se desee) cuando se usen sesiones. Esta cookie guardará un valor, un identificador de sesión, que está asociado con algún tipo de datos en el servidor. Si el usuario tiene una sesión ID válida, los datos asociados con la sesión se incluirán en el superglobal array $_SESSION. Las sesiones pueden también transferirse a través de URL. En ese caso sería algo como ?PHPSESSID=id_aqui.
La sesión ID funciona de forma parecida a la llave de un cajón en un banco, con la que puedes acceder a lo que sea que haya en ese cajón. La llave de tu cajón puede ser robada al igual que puede serlo la sesión ID de usuarios (robada o interceptada). Cuando el atacante roba una sesión ID y trata de usarla para entrar en la aplicación como si fuera el verdadero usuario se le llama session hijacking. Cuando el atacante establece la sesión ID para la sesión de un usuario se denomina session fixation. Estos ataques no se pueden evitar en su totalidad, pero se pueden tomar medidas para prevenirlos. El problema de la seguridad en sesiones aumenta cuando se utiliza un hosting compartido, es decir, usar el mismo servidor que otros usuarios.
La administración de sesiones HTTP es una parte fundamental de la seguridad web. Algunas de las configuraciones más importantes que pueden manipularse en PHP son las siguientes:
_session.cookielifetime = 0. El cero tiene un significado especial, les dice a los navegadores que no guarden una cookie permanentemente. Así pues, si se cierra el navegador, la sesión ID se borra inmediatamente.
_session.usecookies = On y _session.use_onlycoockies = On. Aunque las HTTP cookies tienen algunos problemas, es la forma más recomendable de manejar sesiones.
_session.use_strictmode = On. Esto previene al módulo de sesión iniciar una sesión ID sin inicializar. El módulo de sesión sólo acepta sesión ID válidas generadas por él mismo, rechazando cualquier sesión ID proporcionada por usuarios
_session.cookiehttponly = On. Rechaza el acceso a la cookie de sesión vía JavaScript. Esto previene el robo de cookies a través de JavaScript injection.
_session.cookiesecure = On. Permite el acceso a la cookie sesión ID sólo cuando el protocolo es HTTPS. Si tu aplicación es sólo HTTPS, es recomendable tener activada esta opción.
_session.gcmaxlifetime = [elegir el menor posible]. Número de segundos tras los cuales los datos serán considerados basura y limpiados con posterioridad. Garbage Collection puede ocurrir al inicio de sesión mediante probabilidad. Esta opción no garantiza la eliminación de sesiones antiguas.
_session.use_transsid = Off. El tener esta opción de manejo de session ID transparentes desactivada mejora la seguridad de sesiones eliminando la posibilidad de session ID injection y session ID leak.
_session.referercheck = [tu url original]. Si está activada la opción anterior, session.use_transsid, el uso de esta opción es recomendable, ya que reduce el riesgo de ID injection.
_session.cachelimiter = nocache. Asegúrate de que los contenidos HTTP no son cacheados para sesiones autentificadas. "private" suele usarse para cuando no hay ningún dato de seguridad en el contenido HTTP, y "public" cuando no contiene ningún dato privado en general.
_session.hashfunction = "sha256". Una función hash más fuerte generará una session ID más fuerte. Cuanto más complejo sea el cifrado mejor: sha384, sha512...
4. Convertir los requisitos funcionales a Historias de Usuario
Definimos historia de usuario como la menor unidad de trabajo, que se expresa como un beneficio para los usuarios. Habitualmente las escribimos utilizando la siguiente sintaxis:
Como [personaje], quiero [conseguir algo] para [producir un beneficio]
En las metodologías ágiles, y también en Scrum, las historias de usuario nos sirven para definir las características y funcionalidades de nuestra aplicación. En las metodologías ágiles las historias de usuario nos dan sentido al trabajo que se hace.
Crear buenas historias de usuario nos ayuda a que todos los implicados puedan tomar las decisiones correctas durante la ejecución del trabajo.
Las historias de usuario son una forma de definir un requisito con los objetivos que cada una sea:
- Independiente: Debe ser totalmente atómica en su definición.
- Negociable: Ambiguas en su enunciado para poder ser debatidas. La concreción vendrá dada por los criterios de validación.
- Valorable: Es importante conocer el valor que aportan al proyecto, poder valorar la cantidad de trabajo que suponen para poder planificar y gestionar el proyecto.
- Pequeña: Para poder hacernos una idea rápida una historia de usuario debería poderse llevar a cabo durante un tiempo superior a dos días e inferior a una semana.
- Verificable: Es obligatorio verificar que el software cumple con la funcionalidad acordada, se hace mediante los criterios de validación.
Para definir una historia de usuario debemos responder a las siguientes preguntas. ¿Quién se beneficia de esta historia de usuario? ¿Qué se quiere? ¿Cuál es el beneficio? Para responder estas tres preguntas de una forma clara y comuna en cada uno de los casos lo construiremos a partir de esta frase: "Como ROL quiero ALGO para poder BENEFICIO". Por ejemplo:
El product backlog (o pila de producto) es un listado de todas las tareas que se pretenden hacer durante el desarrollo de un proyecto. Todas las tareas deben listarse en el product backlog, para que estén visibles ante todo el equipo y se pueda tener una visión panorámica de todo lo que se espera realizar.
¿Qué tan extenso puede ser?
Si el proyecto o producto amerita una lista larga, podemos tener cientos o miles de actividades en el product backlog. Nosotros asignamos prioridades sobre el product backlog, en base a las necesidades del cliente y la complejidad de cada actividad. Así mismo, de forma sucesiva, cada sprint produce detalles adicionales, en el diseño, en la funcionalidad, y la verificación de actividades.
¿Cómo se redactan los elementos que van en el Product Backlog?
La forma predominante en un equipo que usa Scrum, es expresar las características en forma de user stories (historias de usuario), que son breves descripciones de la funcionalidad que se desea, contadas desde la perspectiva del usuario. Un ejemplo es: "Como comprador, yo puedo revisar los productos que están en mi carrito de compras antes de confirmar mi compra, y así estar seguro de lo que he seleccionado"
La reunión de planificación del Sprint sigue un flujo y tiene un límite de tiempo de hasta ocho horas para un Sprint de un mes. En este evento es creado por el trabajo colaborativo de todo el Equipo Scrum (Scrum Master, Product Owner y el Equipo de Desarrollo).
El Scrum Master asegura que el evento se lleve a cabo y que los asistentes comprendan su propósito. Esa es la cosa más importante, porqué si no el equipo perderá su motivación y su objetivo. El Scrum Master le enseña al Equipo Scrum a mantenerlo dentro del tiempo.
La Sprint Planning responde a lo siguiente:
¿Qué se puede entregar en el Incremento resultante del próximo Sprint?
¿Cómo se logrará el trabajo necesario para lograr el Incremento?
El trabajo se selecciona de la Pila de productos y se coloca en la Pila de Sprint. Ahora recordamos que el trabajo en el Sprint Backlog no es un compromiso, es un pronóstico (forecast). El único contenedor de un Sprint es su caja de tiempo (timebox), no el trabajo planeado para el Sprint.
La meta del Sprint: El objetivo de Sprint es un conjunto de objetivos para el Sprint que se puede cumplir mediante la implementación de la cartera de productos. Proporciona orientación al Equipo de Desarrollo sobre por qué está construyendo el Incremento. El Objetivo Sprint le da al Equipo de Desarrollo cierta flexibilidad con respecto a la funcionalidad implementada dentro del Sprint. A medida que el Equipo de Desarrollo trabaja, lo hace con el Objetivo Sprint siempre en mente
Conocido también como lista de tareas de la iteración. Es un subconjunto de objetivos/requisitos del Product Backlog seleccionado para la iteración actual y su plan de tareas de desarrollo. El equipo lo elabora en la reunión de planificación de la iteración (Sprint planning) seleccionando lo que prevé que podrá completar y demostrar al cliente al finalizar la iteración, en forma de incremento de producto preparado para ser entregado. El Sprint Backlog una planificación táctica del trabajo a realizar en la iteración actual.
Esta lista permite ver las tareas donde el equipo está teniendo problemas y no avanza, con lo que le permite tomar decisiones al respecto. Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo pendiente para finalizarlas y la auto asignación inicial que han hecho los miembros del equipo.
El progreso de la iteración y su velocidad con respecto a tareas u horas pendientes se puede mostrar mediante un gráfico de trabajo pendiente (Burndown chart).
El tablero de tareas (Scrum Taskboard)
La lista de objetivos a completar en la iteración (Product Backlog Items) se puede gestionar mediante un tablón de tareas (Scrum Taskboard). Al lado de cada objetivo se ponen las tareas necesarias para completarlo, en forma de post-its, y se van moviendo hacia la derecha para cambiarlas de estado (pendientes de iniciar, en progreso, hechas). Para cada miembro del equipo se puede utilizar adhesivos de colores más pequeños sobre cada tarea, de manera que se pueda ver en qué tareas está trabajando cada cual.
5.4 Scrum
La metodología Scrum es un marco de trabajo o framework que se utiliza dentro de equipos que manejan proyectos complejos. Es decir, se trata de una metodología de trabajo ágil que tiene como finalidad la entrega de valor en períodos cortos de tiempo y para ello se basa en tres pilares: la transparencia, inspección y adaptación.
Al estar enmarcada dentro de las metodologías agile, Scrum se basa en aspectos como:
• La flexibilidad en la adopción de cambios y nuevos requisitos durante un proyecto complejo.
• El factor humano.
• La colaboración e interacción con el cliente.
• El desarrollo iterativo como forma de asegurar buenos resultados.
Los pilares o características de la metodología Scrum más importantes son 3:
• 1. Transparencia: Con el método Scrum todos los implicados tienen conocimiento de qué ocurre en el proyecto y cómo ocurre. Esto hace que haya un entendimiento “común” del proyecto, una visión global.
• 2. Inspección: Los miembros del equipo Scrum frecuentemente inspeccionan el progreso para detectar posibles problemas. La inspección no es un examen diario, sino una forma de saber que el trabajo fluye y que el equipo funciona de manera auto-organizada.
• 3. Adaptación: Cuando hay algo que cambiar, el equipo se ajusta para conseguir el objetivo del sprint. Esta es la clave para conseguir el éxito en proyectos complejos, donde los requisitos son cambiantes o poco definidos y en donde la adaptación, la innovación, la complejidad y flexibilidad son fundamentales.
Con la metodología Scrum, el equipo tiene como foco entregar valor y ofrecer resultados de calidad que permitan cumplir los objetivos de negocio del cliente. Para ello, los equipos de Scrum son auto-organizados y multifuncionales. Es decir, cada uno es responsable de unas tareas determinadas y de terminarlas en los tiempos acordados. Esto garantiza la entrega de valor del equipo completo, sin necesidad de ayuda o la supervisión minuciosa de otros miembros de la organización.
En Scrum existen 3 roles muy importantes : Product Owner, Scrum Master y Equipo de desarrollo.
El SPRINT REVIEW (o Revisión del Sprint) es uno de los cinco eventos de Scrum y se realiza al final del Sprint. Durante esta ceremonia se revisa el Incremento, es decir, lo que se realizó durante el Sprint, y se analizan los cambios que tuvo el Product Backlog. El principal objetivo del Sprint Review es obtener feedback de los Stakeholders para inspeccionar y evaluar el producto a fin de ajustar el Product Backlog. A lo largo de la Revisión del Sprint o Sprint Review participa todo el Equipo Scrum, es decir, el Product Owner, el Scrum Master, los Developers y los Stakeholders (los interesados clave, invitados por el Product Owner). El Scrum Master garantiza que el evento se realice y que los participantes comprendan su finalidad.
¿Qué temas deben ser discutidos en el Sprint Review?
• Características determinadas: Todo el equipo Scrum expone los elementos del Product Backlog que se han terminado y los que no.
• Exposición del Incremento del producto: Los Developers presentan el Incremento de Producto, comentan qué problemas surgieron y de qué manera los afrontaron.
• Estado actual y proyección del Backlog: El Product Owner habla acerca del Product Backlog en su estado actual y proyecta futuros objetivos y fechas de entrega basadas en esta nueva información.
• Debate y análisis para el Sprint Planning: Todos los participantes debaten en base al análisis de cómo está el mercado y el uso potencial del producto, sobre qué hacer a continuación. De este modo la Sprint Review proporciona información de entrada valiosa para el próximo evento: la Sprint Planning.
• Revisión del Release Plan: Se revisa y actualiza el Release Plan o plan de entregas del producto y los cambios que hayan podido surgir, como cambios en el presupuesto y las capacidades de el/los equipo/s.
El resultado del Sprint Review, luego de haber inspeccionado y haber recibido feedback sobre el Incremento. es un Product Backlog ajustado, listo para enfocarse en nuevas oportunidades para el siguiente Sprint.
Back End
En el sprint anterior se realizó el diseño de prototipo de nuestro proyecto CB24H, para esta ocasión se mejoró el diseño implementando más estilo y presentación.
- Para esta parte es necesario que el usuario que cuenta con un local inicie sesión dándole clic en la parte que se resalta.
- Seguido aparecerá el siguiente recuadro, si el usuario ya tiene una cuenta ingresa sus datos y le da clic en el botón login, en caso de que aún no tenga cuenta le da clic en el botón registrarse.
- Para que el usuario registre su local rellenara los siguientes datos, ya echo esto continuara dándole clic al botón Continuar.
- Una vez que el usuario ya se haya registrado puede iniciar sesión, así también la opción de registrarse ya no aparecerá.
- Por ultimo como el usuario ya ha creado su cuenta podrá acceder a la siguiente ventana.
Instalamos XAMPP para ocupar de sus servicios.
- Ejecutamos la aplicación XAMPP en nuestro equipo para ocupar el servidor local de Apache.
- Activamos los servicios de Apache y MySQL para que de esta manera poder cargar nuestros archivos al navegador, y así también para realizar pruebas con la base de datos.
- En esta parte está corriendo nuestro Localhost de manera local, para ocupar este servicio nos dirigimos a nuestro navegador y en la barra de búsqueda escribimos localhost/“nombre de la carpeta”.
- Para poder correr nuestro proyecto tenemos que crear nuestra carpeta en la siguiente ruta C:\xampp\htdocs para que de esta manera se pueda ejecutar en el navegador con la ayuda de Apache.
- Abrimos nuestra carpeta para cargar nuestro archivo que tenemos de manera local, por lo que vamos a cargar a nuestro repositorio e GitHub a través de la consola de Git, para esto ocupamos Git init.
- Visualizamos archivos con Git status
- Cargamos todos nuestros archivos y hacemos un commit –m “Archivos del proyecto”, para esto ocupamos el comando Git add.
- Cargamos los archivos al servidor remoto
- Hacemos un git push –u develop que es nuestra rama para subir nuestro proyecto que está en local a Github
Como podemos ver a continuación la aplicación se cargó con éxito
Base de datos online para poder realizar los registros desde la aplicación. Base de datos online free de Amazonaws.
Una vez teniendo nuestro proyecto cargado en el servidor de GitHub la subiremos a un servidor o hosting web que para eso utilizaremos Heruko. Vinculamos con GitHub y seleccionamos nuestro repositorio.
Nota: Creamos una nueva app de nombre coffe-bar.
Ya teniendo el repositorio y las ramas cargadas haremos un Deploy para subir al servidor web y así obtener el link.
Por ultimo realizamos prueba de nuestra aplicación que ya está en la web.
Como podemos ver al cargar un usuario tenemos acceso a nuestra página principal.
Con la elaboración de esta práctica se tocaron todos los temas relacionados a la elaboración de proyectos, en este caso logramos trabajar de una manera más extensa y profunda lo que anteriormente conocimos como metodología SCRUM, conocimos y aprendimos lo que es una aplicación web responsiva y que ventajas tienen ante una aplicación web, es por ello que nuestro proyecto está enfocado a ser una aplicación web responsiva, dando a entender que queremos que esta funcione en cualquier plataforma y/o dispositivo, así mismo aprendimos sobre la seguridad en el lenguaje php y los comandos a utilizar para obtener un aplicación segura, encontramos la manera de convertir nuestros requisitos funcionales a historias de usuario, las cuales tienen que estar bien elaboradas para poder tomar las mejores decisiones en el equipo. Dentro de la metodología SCRUM para desarrollar este sistema, relacionamos los puntos más importantes como los sprint planning y backlog, así como el product backlog y estos los pusimos en práctica para así poder culminar esta parte y obtener un sistema de calidad como se nos fue requerido. Es muy importante seguir todo en el orden especifico e irnos basando en los ejemplos que se nos presenten para no tener dificultades en la elaboración de este tipo de trabajos.
- https://www.scrum.org/resources/what-is-a-sprint-review
- https://www.scrum.org/resources/blog/que-es-la-sprint-planning-y-que-flujo-sigue-para-el-equipo
- https://proyectosagiles.org/lista-tareas-iteracion-sprint-backlog/
- https://programacionymas.com/blog/scrum-product-backlog#:~:text=El%20product%20backlog%20en%20Scrum,al%20inicio%20de%20un%20proyecto
- https://diego.com.es/seguridad-de-sesiones-en-php
Introducción
Objetivo de la práctica
Materiales
- Seguridad de App con sesiones en PHP y encriptación de datos.
- Diseñar la base de datos
2.1 Diseño de tablas con campos y atributos
2.2 Procedimientos y funciones.
- Aplicación de la metodología SCRUM para el desarrollo
- Diseñar y mejorar el mockup que fue realizado en el sprint anterior, validarlo con el cliente
- Configuración de ambiente remoto con GitHub y Heruko.
- Probar el login final y validar con el cliente final.
- Realizar según la aplicación que se vaya a realizar el Módulo 1 ya sea (clientes, artículos, compras, etc.)
Link de la aplicación
Conclusión
Bibliografías
El Backend, también conocido como CMS o Backoffice, es la parte de la app que el usuario final no puede ver. Su función es acceder a la información que se solicita, a través de la app, para luego combinarla y devolverla al usuario final.
Acceder a la información que se pide, a través de la app: cuando usamos una aplicación móvil pedimos información de manera continua, no importa si la app es de búsqueda de información, un juego o una red social. Esto implica que una parte de la app (el Backend), tiene que ser capaz de encontrar y acceder a la información que solicitemos. El proceso de búsqueda de datos no es fácil, ya que estos se almacenan en grandes bases de datos (en plural), que se encuentran, además, protegidos para no exponer lo que en nuestra área se denomina información sensible. En este punto, un Backend bien diseñado debe ser capaz no sólo de encontrar la información precisa que el usuario requiere, sino también de acceder a ella de manera segura.
Combinar la información encontrada y transformarla: Una vez encontrada, el Backend combina la información para que resulte útil al usuario. Pongamos, como ejemplo, una aplicación de transporte y una orden de búsqueda: “cómo llegar del trabajo a casa”.
Devolver la información al usuario: Finalmente, el Backend envía la información relevada de vuelta al usuario. Pero, ¿cuántos usuarios son capaces de leer datos escritos en código puro? Pocos. Es por ello que el Backend necesita de traductores capaces de convertir los datos escritos en código a lenguaje humano. Es aquí donde intervienen las famosas APIs, trabajando en conjunto con el Frontend.
En pocas palabras, las APIs son las herramientas encargadas de transportar la información desde el Backend hasta el Frontend, que es donde el proceso final de traducción toma forma, y donde la información escrita en código se convierte en los diseños, las imágenes, las letras y los botones que el usuario final entiende y con los que puede interactuar.
Este proceso es hecho por en Frontend en dos fases, que tienen lugar en dos subcapas que conforman su estructura:
La subcapa lógica, relacionada con el lenguaje específico, en el que la app ha sido desarrollada. Como ya sabemos, las apps pueden ser desarrolladas para distintos sistemas operativos -iOS, Android, WindowsPhone…- que requieren ser escritas en distintos lenguajes de código. En este punto, la subcapa lógica del Frontend se encarga de hacer una primera traducción del lenguaje en el que las APIs envían la información al lenguaje específico de cada sistema operativo. Este es un proceso que, a pesar de ocurrir en el Frontend de nuestra app, el usuario final no ve. Podríamos llamarlo el “Backend del Fronted”
- Rediseñar Mockups
- Diagrama de base de datos
- Codificación
- Pruebas locales(XAMPP)
- Pruebas remotas(Gity GitHub)
- Servidor en la nube base de datos
- Subir aplicación a Heruko
- Internet
- Computadora
- Visual Studio Code.
- XAMPP
- Git
- GitHub
- Heruko
- AMAZONAWS
Para que los datos de nuestros usuarios no corran peligro hemos encriptado sus contraseñas mediante hash5 la cual convierte sus contraseñas en caracteres ofreciendo una mejor seguridad de los datos y así evitar que hagan una inyección de SQL.
Para estar seguros de que esto funciona hemos realizado una prueba para comprobar que al momento de guardar un usuario este se esté encriptado. Como podemos ver a continuación efectivamente se han encriptado exitosamente.
Para nuestra base de datos diseñamos un modelo ER para la conexión entre tablas que contara un usuario y de qué manera se conectan los campos en la aplicación.
Una vez creada el modelo de ER crearemos los campos de cada una de nuestras tablas.
Revisamos que los campos del se hayan creado conforme al modelo ER.
Seguimos los pasos anteriores y creamos todas nuestras tablas para nuestra aplicación.
Para crear nuestra aplicación vamos a utilizar y crear archivos que nos permitirá navegar entre los archivos y así cargar las rutas que definiremos para cada ventana que deseemos navegar, por lo que utilizaremos un modelo conocido como MVC (MODELO-VISTA-CONTROLADOR.)
A continuación mostramos la manera en la que se carga un controlador para luego poder visualizar nuestra vista.
En la parte de modelo es donde se ejecutara todo el código QUERY de MYSQL como la carga de datos del formulario en nuestra aplicación y es donde hará el proceso de inserción a la base de datos.
En el modelo de vista cargamos todos los archivos que se cargaran para que pueda ver el usuario cuando navegue en nuestra aplicación.
Al implementar la metodología SCRUM se tiene como objetivo desarrollar la aplicación de una manera ágil generando entregas incrementales en lugar de realizar una planificación y ejecución completa del desarrollo del software. Para el desarrollo de la aplicación web que permitirá el cálculo automático de horas extra para los conductores de una empresa de transporte se definió la metodología ágil scrum, la cual acelerará las entregas del proyecto para así suplir de manera rápida la necesidad que tiene esta empresa.
El documento se divide en una serie de capítulos que a su vez se subdividen en apartados. Los capítulos son los siguientes:
- Introducción: da una visión global del proyecto, exponiendo los objetivos a alcanzar, él porque de la realización de este proyecto y el contexto.
- Análisis del sistema: es un estudio previo al desarrollo en el cual se detalla las propiedades del sistema y los elementos que se deben desarrollar.
- Desarrollo del sistema: en este capítulo se detalla todo lo relativo al propio desarrollo del proyecto.
- Planificación y presupuesto: se expone la planificación previa basada en las estimaciones para la duración del proyecto y se realiza un pequeño análisis económico de éste para hallar el coste final de su realización.
- Conclusiones: último capítulo del documento en el cual se plasman las conclusiones extraídas después de la finalización del proyecto, tanto personales como de resultados. También se proponen desarrollos futuros que enriquezcan al sistema.
En el sprint anterior se realizó el diseño de prototipo de nuestro proyecto CB24H, para esta ocasión se mejoró el diseño implementando más estilo y presentación.
-
- Para esta parte es necesario que el usuario que cuenta con un local inicie sesión dándole clic en la parte que se resalta.
-
- Seguido aparecerá el siguiente recuadro, si el usuario ya tiene una cuenta ingresa sus datos y le da clic en el botón login, en caso de que aún no tenga cuenta le da clic en el botón registrarse
-
- Para que el usuario registre su local rellenara los siguientes datos, ya hecho esto continuara dándole clic al botón Continuar.
-
- Una vez que el usuario ya se haya registrado puede iniciar sesión, así también la opción de registrarse ya no aparecerá.
-
- Por ultimo como el usuario ya ha creado su cuenta podrá acceder a la siguiente ventana.
Abrimos nuestra carpeta para cargar nuestro archivo que tenemos de manera local, por lo que vamos a cargar a nuestro repositorio e GitHub a través de la consola de Git.
Cargamos todos nuestros archivos y hacemos un commit –m “Archivos del protecto”….
Hacemos un git push –u develop que es nuestra rama para subir nuestro proyecto que está en local a Github
Resultado: Como podemos ver a continuación la aplicación se cargó con éxito.
Base de datos online para poder realizar los registros desde la aplicación. Base de datos online free de Amazonaws.
Una vez teniendo nuestro proyecto cargado en el servidor de GitHub la subiremos a un servidor o hosting web que para eso utilizaremos Heruko. Vinculamos con GitHub y seleccionamos nuestro repositorio. Nota: Creamos una nueva app de nombre coffe-bar.
Ya teniendo el repositorio y las ramas cargadas haremos un Deploy para subir al servidor web.
Por ultimo realizamos prueba de nuestra aplicación que ya está en la web.
Como podemos ver al cargar un usuario tenemos acceso a nuestra pagina principal
7. Realizar según la aplicación que se vaya a realizar el Módulo 1 ya sea (clientes, artículos, compras, etc.)
El cliente podrá registrarse o crear un nuevo usuario con características de su negocio.
Como podemos al registrar un nuevo usuario al igual que el local podemos ver que nuestro registro se almaceno correctamente a nuestra base de datos que tenemos de manera remota en Amazonaws.
Visualizamos nuestra base de datos y podemos observar que el usuario se almaceno correctamente a nuestra base de datos y con la contraseña encriptada.
https://coffe-bar.herokuapp.com/
En la creación de la aplicación hemos utilizado un modelo MVC (MODELO-VISTACONTROLADOR) la cual nos permite un mejor tener un control para nuestros usuarios y de igual manera una mejor arquitectura de software que nos permiten clasificar mejor nuestra información, como lo es la lógica del sistema y la interfaz que se le presenta al usuario final. Las pruebas y controles de nuestra aplicación la hemos trabajado tanto de manera local como remota. De manera local hemos trabajado con un servidor local xampp la cual nos permite realizar pruebas de nuestra aplicación desde un localhost y así poder obtener buenos resultados antes de subirlo a un servidor web, por otro lado para realizar actualizaciones o modificaciones a la aplicación hemos utilizado las herramientas Git hash here la cual es una herramienta muy potente que nos ayuda a hacer actualizaciones al repositorio remoto y llevar un control de commits. De igual manera para tener un servicio de base d datos en la nube hemos utilizado una Base de datos en la nube para la inserción de datos en nuestra aplicación la cual hemos utilizado una versión gratuita de amazonaws en Mysql. Teniendo todos estos requisitos hemos subido la aplicación a un servidor gratuito la cual nos permite subir nuestras aplicaciones, el servidor se llama Heruko la cual tiene una versión gratuita que nos basta para subir aplicaciones a su servidor web.
- Servidor heruko. (s. f.). Heruko. Recuperado 26 de mayo de 2021, de https://id.heroku.com/login
- Repositorio remoto. (s. f.). GitHub. Recuperado 26 de mayo de 2021, de https://github.com
- Servidor local. (s. f.). https://www.apachefriends.org/es/index.html. Recuperado 26 de mayo de 2021, de https://www.apachefriends.org/es/index.html