ParkN'Go: Plataforma de alquiler de garajes - DSpace

Se realiza con el objetivo de mejorar la calidad del código que se genera en el proceso de desarrollo. SQA (Software Quality Assurance): Se refiere al aseguramiento de la calidad del software en el proyecto.

Introducción

Objetivos

Objetivos académicos
Objetivos de equipo
Objetivos del producto

Ser capaz de aplicar todos los conocimientos adquiridos a lo largo del curso en la práctica en un proyecto propio. Aplicar los conocimientos técnicos adquiridos a lo largo de la carrera para poder generar un producto de alta calidad que esté abierto al cambio y pueda acompañar el negocio cambiante.

Contenido del documento

La capacidad de trabajar habilidades que no adquirimos durante los estudios, que nos ayudan a estar mejor preparados profesionalmente. Garantizar una buena experiencia a los usuarios es crucial para el éxito de ParkN'Go, ya que son esenciales para el funcionamiento de la empresa.

Descripción del problema

El problema y su contexto

Descripción del problema

Interesados

Como funciona el negocio

Investigación de campo

Encuestas
Entrevistas

Desafíos

Desafíos de emprendimiento
Desafíos del proyecto

Solución planteada

Marco metodológico

Características del proyecto

El proyecto desarrollado tiene las características de un emprendimiento, lo que trae consigo una serie de desafíos que no están previstos en el proyecto del cliente. La inexistencia de un cliente traía consigo un riesgo difícil de controlar, al no existir indicaciones ni requerimientos en forma de solicitud de parte interesada, como suele ser el caso de un cliente.

Características del equipo

Ciclo de vida

Justificación de elección
Fases del ciclo de vida

La fase de construcción tuvo como objetivo implementar el diseño de solución resultante de las fases de Requisitos y Diseño Arquitectónico. En la fase de pruebas el objetivo fue controlar el correcto funcionamiento de la aplicación.

Adaptación de Scrum

Ceremonias
Artefactos
Herramientas y tecnologías

El propósito de las reuniones es planificar las tareas a completar en el Sprint y agregarlas al Sprint Backlog. En el caso de que no se completaran todas las tareas planificadas, se intentó determinar el motivo por el cual no se logró el objetivo.

Roles establecidos

El uso de esta herramienta se describe en detalle en el capítulo de gestión de proyectos, sección 6.8. La razón para utilizar una herramienta dinámica como WhatsApp está relacionada con el hecho de que las metodologías ágiles se centran en la comunicación del equipo más que en la documentación.

Beneficios del modelo ágil

Flexibilidad con respecto al cambio
Entregas tempranas
Alineamiento entre usuarios e integrantes

Ingeniería de requerimientos

Proceso de ingeniería de requerimientos

Estudio de factibilidad
Extracción y análisis de requerimientos

Encuestas
Actividades de Design Thinking
Tareas de extracción y análisis con grupo foco
Ingeniería reversa
Entrevista a colegas

Especificación

Identificación de funcionalidades
Requerimientos funcionales
Requerimientos no funcionales

Validación de requerimientos

Prototipos utilizados
Tareas validación con grupo foco
Instancias de validación de producto interno

Actividades transversales al proceso de ingeniería

Grupo foco
Diseño centrado en el usuario

Arquitectura

Descripción general

Diagrama de Contexto

Catálogo de Componentes

Elección de tecnologías

Aplicación Móvil
Backend
Aplicación Web
Hosting

Principales atributos de calidad

Usabilidad
Mantenibilidad
Portabilidad
Seguridad

Vista de componentes y conectores

Vista de despliegue

Desarrollo

Organización del código
Plan de releases
Capacitación
Sprints
Pull Requests
Integración del código
Gestión de dependencias

Gestión de proyecto

Organización de trabajo

Negocio
Investigación
Desarrollo
Documentación final

Gestión de roles

Adaptación de roles

Planificación por iteración

Proceso de iteraciones
Estimaciones

Gestión del alcance

Gestión del product backlog
Plan de release

Ejecución del proyecto

Ejecución de iteraciones

Sprints

Métricas

Velocidad
Burndown chart
Esfuerzo
Gráfico de productividad
Desvió entre esfuerzo real y estimado

Gestión de la comunicación

Gestión de riesgo

Identificación de riesgos
Análisis de riesgos
Riesgos del proyecto
Control y monitoreo
Riesgos materializados

Gestión de calidad

Objetivos de calidad

Producto
Proceso

Para asegurar la calidad se estableció una serie de objetivos tanto a nivel de producto como de proceso, que debían ser cumplidos por el equipo durante todo el proyecto. El equipo propuso varios objetivos para el proceso que le permitieron rastrear la correcta alineación del proyecto. A lo largo del proyecto, el equipo invirtió 198 horas en actividades de calidad, lo que corresponde al 11% del esfuerzo total (ver sección 6.7.3).

De este análisis podemos concluir que, por cada 10 horas de desarrollo, se dedicaron 2 horas a la calidad. Para cada sprint, se decidió registrar si el equipo logró alcanzar todos los objetivos previamente establecidos en función de la escala de calidad de la iteración en cuestión.

Plan de la calidad

Aseguramiento de la calidad

Uso de idioma inglés
Estándares de código
Estándares de documentación
Estándares para control de versión y repositorios
Aseguramiento de los estándares aplicados
Revisiones
Validación

302 FI Normas especiales para la presentación de proyectos finales de carrera de la Facultad Técnica. 303 Lista de Verificación Instructivo para la presentación de trabajos finales de la Facultad Técnica. Se utilizó Google Docs para el control de versiones de la documentación durante todo el proyecto y se eligió Microsoft365 para la documentación final.

Dependiendo de la tecnología se utilizaron diferentes herramientas para asegurar el correcto uso de los estándares establecidos. Por otro lado, para el diseño de la base de datos se realizaron validaciones con los expertos Cecilia Belletti y David Giménez.

Pruebas de software

Pruebas unitarias
Pruebas funcionales
Pruebas de portabilidad
Alpha testing

Instancias
Satisfacción de usuarios

123 Por otro lado, cabe señalar que las instancias de validación se realizaron a través de las pruebas especificadas en el apartado 7.4. El cuadro 11.20, en la sección Análisis de retroalimentación, presenta estos eventos en detalle. En esta ocasión, el equipo pudo corregir gran parte de las incidencias descubiertas en la primera evaluación.

Además, como se mencionó en la sección anterior, hubo un total de 2 casos en los que el equipo se comprometió a no bajar el resultado obtenido en comparación con la evaluación anterior. Como se puede observar en la Figura 33, se cumplieron ambos objetivos propuestos por el equipo.

Gestión de incidentes

Finalmente, cabe destacar que en la primera evaluación, el 75% de los usuarios tuvo problemas con algunas funciones. Cuando se trata de manejar incidentes, el equipo ha decidido tratarlos igual que cualquier historia de usuario. Cabe señalar que el equipo utilizó errores para registrar errores y tareas para registrar mejoras.

Verificación

Métricas

Métricas del proceso
Métricas del producto

El objetivo se superó en más de 15 puntos, lo que garantizó que todos los archivos menos uno (con una puntuación de 49,56) alcanzaron individualmente el objetivo del equipo. El equipo consideró correcto un conjunto de pruebas si el porcentaje de aprobación era del 100 % y si la cobertura del código excedía el 80 %. Para determinar este criterio, el equipo se basó en el artículo de Martin Fowler sobre TestCoverage [52], que menciona que se espera un porcentaje superior al 80% si se prueba correctamente.

Para medir la usabilidad, el equipo se basó en la métrica del "tiempo de finalización" [53], que consiste en medir cuánto tiempo les tomó a los usuarios completar las funciones de la aplicación. 135 De esta manera, el equipo pudo descubrir las funcionalidades que resultaban más confusas para los usuarios y, de ser necesario, poder aplicar tácticas y modelos de usabilidad para corregir el tiempo promedio empleado.

Gestión de configuración

Elementos de la configuración

Repositorios

Código fuente
Metodología de trabajo

Documentación

Gestionado de versiones

Ambientes

Conclusiones y aprendizajes

Estado actual

Actualmente, el equipo continúa trabajando con los usuarios y ultimando detalles a nivel de interfaz de usuario y en términos de integración con la plataforma de pagos Stripe, que actualmente se encuentra en un entorno de prueba. Una vez que esté en funcionamiento, será necesario actualizar la configuración de su cuenta para comenzar a procesar pagos reales. En cuanto a la implementación de la solución, la interfaz web está en producción y lista para funcionar.

El backend se instala en el entorno de preproducción, pero cuenta con todo lo necesario para pasar a producción cuando se considere oportuno. En materia de riesgos del negocio, aún queda trabajo por hacer (por ejemplo, asesoría y cumplimiento de la Ley 18.331) para preparar su lanzamiento libre de riesgos.

Conclusiones

Conclusiones de los objetivos académicos
Conclusiones de los objetivos de equipo
Conclusiones de los objetivos del producto

145 Consideramos que este objetivo se cumplió satisfactoriamente, ya que el equipo adquirió conocimientos de Flutter y React con los que no tenía experiencia previa, y logró consolidar los conocimientos que tenía de Node.js. Consideramos que el proyecto fue un ejemplo enriquecedor que nos permitió integrar y poner en práctica los conocimientos teóricos de diferentes áreas de conocimiento de la ingeniería de software, obtenidos durante la graduación. Aunque el equipo nunca había ejercido formalmente funciones de ingeniería, cada miembro pudo desempeñar su función correctamente.

Como resultado de las decisiones arquitectónicas y de aseguramiento de la calidad, podemos confirmar que se ha conseguido un producto de calidad, extensible y abierto al cambio, cumpliendo el objetivo establecido. Gracias a las sesiones de validación con potenciales usuarios y al feedback recibido, también podemos constatar que el producto generado es un sistema atractivo e intuitivo con gran aceptación por parte de los usuarios consultados.

Aprendizajes

Al principio fue confuso y delicado lidiar con los diferentes puntos de vista y opiniones con los que tienes que lidiar. Esto último no sólo ayudó al equipo a comprender más fácilmente las necesidades de los usuarios, sino que también le otorgó una importante capacidad relacionada con intuir o predecir las necesidades de los usuarios potenciales antes de que las expresen. Haber aprendido a empatizar con las personas es uno de los aprendizajes más valorados del equipo, ya que incidirá directamente en proyectos futuros y facilitará los procesos de saber más sobre la empresa en la que trabajarán.

En el proceso de identificación y priorización de atributos de calidad se produjeron discusiones con el equipo y con expertos en la materia, que fueron realmente enriquecedoras. Gracias al seguimiento, el equipo se propuso cambiar la duración de los sprints en el último tramo del proyecto, pudiendo aumentar el rendimiento para alcanzar los objetivos marcados.

Próximos pasos

Disponible: https://www.elobservador.com.uy/nota/parking-subterraneo-de-villa-biarritz-divide-a-los-vecinos-2017825500. Disponible: Este artículo puede verse en este enlace: https://www.elobservador.com.uy/nota/cuanto-cuesta-trabajo-cocheras-y-apartamentos-segun-el-barrio-de-montevideo-2018815500. Disponible: https://academind.com/learn/flutter/react-native-vs-flutter-vs-ionic-vs-nativescript-vs-pwa/.

Anexos

Encuesta

Entrevistas a porteros

¿Cómo te sentirías si te asignaran una nueva tarea? Después del rodaje comentó que no tendría ningún problema con sus vecinos, con quienes tiene buenas relaciones, pero con quienes tiene roces, que preferiría no hacerles un favor, y luego lo pienso y agrego. que todos en el edificio son sus jefes. y si le dan una orden, la cumplirá. Si tuvieras que comprobar el acceso del coche al garaje, ¿cómo lo harías?

Si tuvieras que comprobar el acceso de los coches al garaje, ¿cómo lo harías? ¿Cómo se sentiría si le asignaran una nueva tarea, como comprobar que vehículos extranjeros entren al edificio?

Encuesta de la tercera reunión con grupo foco

Mapa de empatía

Insights

El usuario sólo tiene que pagar por el tiempo que deja el coche aparcado, para no malgastar dinero si no lo utiliza. El usuario necesita un lugar seguro donde dejar su vehículo para reducir el miedo a su integridad física y al robo. El usuario deberá disponer de un lugar donde aparcar el coche para empezar a utilizar su vehículo y dejar de utilizar el transporte público.

Mindmap

Conclusión primera reunión con el grupo foco

Sugerencias tercera reunión grupo foco priorizadas

Sería bueno que cuando aparezcan las opciones disponibles superes la 1 hora o. Mejorar la ventana de reserva, seleccionar horarios con anticipación para reservar (al hacer clic en una disponibilidad se cargará el rango de tiempo) Sugerencia 5 1 5.

Entrevistas con colegas

Si no tienes la aplicación abierta debería haber una notificación, y si está abierta debería agregarse al calendario que mencioné y notificar. ¿Qué características "intangibles", es decir, aquellas que no son funcionalidades, crees que debería tener una aplicación? Imagínese enviar 2 a su garaje para obtener información sobre sus reservas.

Dentro de la información de mis garajes puedo ver la reserva de cada uno y también en conjunto. Me gustaría poder ingresar los datos del conductor, evaluar la calificación dada por otros para aceptar o rechazar.

Diagramas de actores y entidades

Requerimientos funcionales

Requerimientos no funcionales

Inspecciones de interfaces de usuarios de colegas

Análisis de tecnologías a utilizar

Análisis de tecnologías móvil
Análisis de tecnologías Backend
Análisis de tecnologías web

196 Por otro lado, las principales debilidades de esta alternativa son su rendimiento, que puede impactar la usabilidad, y las limitaciones para acceder a las funcionalidades nativas del dispositivo. Si eligiera React Native [61], NativeScript [62] o Ionic [63], solo se desarrollaría en el lenguaje JavaScript [64]. Elegir esta opción colocaría la responsabilidad de capacitar y desarrollar toda la aplicación en un miembro.

En el proyecto no existen requisitos que justifiquen la necesidad de aprovechar al máximo las prestaciones que ofrece esta alternativa, ni el acceso a funcionalidades nativas muy concretas que no se pueden conseguir con ningún otro enfoque. Además, dado que el equipo tiene experiencia desarrollando tanto en Java como en C# y tiene una importante experiencia en desarrollo front-end utilizando JavaScript, adoptar Dart como lenguaje de programación no parece plantear ningún problema.