OpenSpace: Se refiere al evento realizado o en general al evento configurado dentro de la plataforma. 9 SQA: El aseguramiento de la calidad del software (SQA) es una forma y práctica de monitorear los procesos y métodos de ingeniería de software utilizados en un proyecto para garantizar una calidad adecuada del software [32].
Introducción
- Presentación del equipo
- Selección del proyecto
- Objetivos
- Producto
- Aprendizaje
- Académico
- Presentación del cliente y producto
- Estructura del documento
- Descripción del problema y la solución
- Marco metodológico
- Ingeniería de requerimientos
- Arquitectura
- Construcción
- Gestión del proyecto
- Gestión de la calidad
- Aprendizajes y conclusiones
El objetivo de la plataforma actualmente es poder gestionar toda la dinámica de los temas hasta el punto previo a la reunión física. Se detalla cómo trabajó el equipo en la fase de desarrollo, que es el proceso que requiere mayor esfuerzo.
Descripción del problema y la solución
- El problema y su contexto
- Principales interesados
- Objetivo de la solución
- Descripción general de la solución
Dispone también de un informe de rendimiento en la aplicación y genera fácilmente una agenda que podrás compartir con los usuarios en tiempo real. Esta aplicación está diseñada para funcionar en teléfonos móviles inteligentes con conexión a Internet, ya que los datos se cargan directamente en la parte inferior de la plataforma.
Marco metodológico
- Características del proyecto
- Selección y definición del ciclo de vida del proyecto
- Metodología de referencia
- Roles
- Artefactos
- Ceremonias
- Proceso de desarrollo
Hizo visible todo el trabajo que el equipo de desarrollo identificó como necesario para lograr el objetivo del Sprint. El propietario del producto [34] prioriza estas historias de usuario [31] en el registro del proyecto, dejándolas listas para ser discutidas durante la ceremonia de la reunión de planificación del Sprint por parte del equipo.
Ingeniería de requerimientos
- Relevamiento
- Entrevistas
- Observación
- Prototipado
- Benchmarking
- Brainstorming
- Especificación de requerimientos
- Requerimientos funcionales
- Registro
- Product Backlog
- Requerimientos NO funcionales
- Validación
- Requerimientos funcionales
- Requerimientos No Funcionales
- Entregables
Título: texto breve que identifica el requerimiento del usuario en el formato "Como [rol] quiero que una [funcionalidad] alcance un determinado [valor]. Como usuario quiero ver detalles de una propuesta Propuesta Alta 3 8 Como administrador I Quieres crear pistas para una sesión.
Arquitectura
- Descripción general
- Diseño
- Diagrama de despliegue
- Diagrama de paquetes
- Atributos de calidad
- Mantenibilidad
- Portabilidad
- Interoperabilidad
- Usabilidad
- Performance
- Tecnologías
- Front-end
- Aplicación móvil
- Back-end
- Base de datos
- Cloud
- Database Service
Persistencia Este paquete es responsable de la persistencia de todas las entidades de la plataforma en la base de datos [3]. A nivel de aplicación web [13] y aplicación móvil [26], operaciones simples y asincrónicas propias del uso de tecnología Angular [37].
Construcción
- Capacitaciones
- Estrategia de desarrollo
- Herramientas utilizadas
- Conclusiones
Al principio, tomamos la decisión de que tres miembros del equipo deberían poder hacer todo, que cada uno de nosotros debería desarrollar funcionalidades completas desde el back-end [25] hasta el front-end [24], lo que significa que todos los desarrolladores lo saben todo. tecnologías y aplicaciones. Por un lado, reconocimos las ventajas de tener a todos los miembros trabajando en todos los niveles del producto, donde cada uno podría ser responsable de una funcionalidad específica, lo que nos permitió aprender todas las tecnologías, lo que generó un crecimiento profesional adicional. Los tres miembros del equipo discuten y toman todas las decisiones juntos, por lo que enfatizan el trabajo en equipo, sin necesidad de un líder.
Gestión del proyecto
Gestión del alcance
- Definición del alcance
- Plan de release
- Candidato: 1
- Candidato: 2
- Release Final
Como Usuario quiero ver los detalles de una propuesta. Propuestas Como Usuario quiero agregar un Comentario a una propuesta. Como administrador quiero ver las observaciones del moderador registrado de un OpenSpace en cada pista para evaluar el resultado. Como usuario, quiero que la leyenda de la combinación de Aperturas actual seleccionada tenga una etiqueta que diga Evento para que quede más clara.
Gestión del esfuerzo
- Herramientas utilizadas
- Métricas de esfuerzo
Luego se crea el siguiente gráfico para representar estas actividades, indicando las horas dedicadas y su porcentaje del total de horas de esfuerzo del proyecto. Se presenta el siguiente gráfico mostrando el esfuerzo puesto en el proyecto en horas por mes. El gráfico muestra que el esfuerzo dedicado al proyecto es igual entre los miembros del equipo.
Ejecución de iteraciones
- Velocidad
- Productividad
Aquí hay un gráfico que muestra cómo cambió la velocidad del equipo a lo largo del proyecto, lo que representa una velocidad promedio de 20 puntos de historia por sprint. Todas las tareas a realizar en el proyecto (tanto de construcción como de soporte) se estimaron en puntos de historia. Finalmente, se presenta un gráfico Burn Down [132] para mostrar cómo se realizó o consumió el trabajo total realizado durante el proyecto.
Gestión de riesgos
- Identificación
- Análisis
- Actividades preventivas
- Seguimiento de riesgos
Dado que no se estiman todas las historias de usuarios [31] en el backlog y hay una fecha de entrega fija, existe incertidumbre sobre si todas las historias se cumplirán. Estima todas las historias de usuario lo más rápido posible y calcula la velocidad que necesitamos para terminarlas. A partir del sprint 4 se descubrió que no se cumplían todas las historias, ya que no se estimaron todas las historias y no se sabía cuánto tiempo se dedicaría a esto.
Comunicación
WhatsApp [98] se utilizó como una herramienta de comunicación informal e instantánea entre los miembros del equipo, el propietario del producto y el tutor. Se eligió porque es una herramienta de uso diario y familiar para todos los miembros del equipo y las partes interesadas del proyecto. Esta herramienta nos permitió tener un espacio de trabajo colectivo, abierto a todos los miembros del equipo, colaborativo y transparente.
Gestión de la calidad
Objetivos de calidad
- Del proceso
- Del producto
- Académicos
106 Dentro de los requisitos no funcionales, la durabilidad es uno de los objetivos más importantes, ya que este es un problema importante que nuestro cliente tiene con el producto hoy. Además, generalmente se espera que el producto alcance el nivel de calidad estándar para este tipo de aplicación en el mercado, es decir, que funcione correctamente en un entorno de usuario similar al entorno real del cliente.
Plan de calidad
Cumplir con todos los requisitos requeridos para el último año del proyecto y elaborar un documento final que cumpla con los estándares exigidos por la Universidad ORT Uruguay establecidos en los documentos no.
Aseguramiento de la calidad
- Mantenibilidad
- Usabilidad
- Benchmarking de usabilidad
- Análisis Heurístico
- Resultados Heurísticos
- Mocks
- Validaciones de usabilidad
- Oportunidades de mejora
- Uso de estándares
- Estándares de codificación
- Estándares de documentación
- Verificación de los estándares aplicados
Gracias a estos análisis se han realizado mejoras en el producto que se detallan en el siguiente capítulo. El campo de error no está claramente identificado en el formulario de creación y modificación de un Espacio Abierto. El campo de error no está claramente identificado en el formulario de creación y edición de la propuesta.
Pruebas de software
- Pruebas unitarias
- Pruebas de integración
- Pruebas de sistema
- Pruebas de portabilidad
- Prueba de satisfacción con el cliente
- Pruebas de performance
Se realizaron pruebas unitarias en el backend [25], tanto a nivel de controlador API como a nivel de servicio. La aplicación web ha sido probada en varios navegadores y resoluciones, que se describen en la siguiente tabla. La aplicación Apache JMeter [73] se utilizó para simular simultáneamente solicitudes a los diversos puntos finales API mencionados anteriormente.
Revisiones
El equipo pudo verificar que la autenticación con Azure Active Directory [52] usando grupos tenía problemas de rendimiento que algunos usuarios de la comunidad comentaron. Para solucionar el problema, se decidió pasar a utilizar roles en Azure Active Directory [52] utilizando la biblioteca de autenticación MSAL [119]. 133 A nivel de documentación y procesos, hubo revisiones determinadas por la Universidad ORT Uruguay, que resultaron en mejoras significativas en cuanto al proceso y metodologías.
Validaciones
Gestión de incidentes
En el siguiente gráfico podemos ver cómo se distribuyeron las incidencias en los diferentes Sprints. Los acontecimientos fueron catalogados según la epopeya [51] a la que pertenecen, por lo que podemos ver cómo se distribuyeron por epopeya [51] en el siguiente gráfico. En el siguiente gráfico podemos ver el tiempo total empleado en desarrollar el producto en relación a las horas de postprocesamiento.
Conclusiones
También fue posible detectar problemas de rendimiento gracias a las pruebas realizadas que pudieron corregirse. De igual forma, las pruebas unitarias, de integración y de sistemas ayudaron a detectar oportunamente defectos en la aplicación, lo que incidió en el bajo retrabajo como se mencionó anteriormente, esto nos permitió enfocarnos en nuevas funcionalidades y no en la corrección de defectos.
Gestión de la configuración
Identificación de los elementos de configuración
Elección de herramientas
- Software
- Repositorios
- Documentación
Un segundo repositorio llamado pops-web para el front end [24] de la aplicación web y un back repositorio para el front end [24] de la aplicación móvil llamado pops-app. Por otro lado, como ya se mencionó, se utilizó el paquete de Google para crear las diapositivas necesarias para las presentaciones requeridas por la Universidad ORT. También se mantuvo una hoja de cálculo con los distintos casos de prueba que se crearon y hojas de diseño.
Conclusiones y lecciones aprendidas
Cumplimiento de objetivos
- Producto
- Aprendizaje
- Académicos
Aprobar el proyecto final y realizar una oferta académica de calidad según los estándares de la Universidad ORT. Para gestionar el proyecto y al mismo tiempo entregar el producto a satisfacción del cliente, el equipo tuvo que aplicar los conocimientos adquiridos a lo largo de sus carreras. Queda por ver si hemos cumplido el objetivo de aprobación del borrador final, ya que al momento de presentar este documento no se conoce el resultado; sin embargo, creemos que es muy probable que esto suceda, según las consideraciones que acabamos de mencionar.
Conclusiones generales
Lecciones aprendidas
Como resultado y basándose en sugerencias de tutores y jueces, el equipo definió una nueva medida, la productividad del equipo. La importancia de gestionar los riesgos fue una de las lecciones más importantes que aprendió el equipo. La gestión de estos riesgos permitió al equipo anticiparlos y gestionarlos satisfactoriamente.
Ojeguereko: https://es.wikipedia.org/wiki/Angular_(marco) [38] Wikipedia, “Ionic(marco de aplicación móvil).” [Liñoitére oĩva]. Ojeguereko: https://es.wikipedia.org/wiki/Planning_poker [107] Wikipedia, "Kuatia estilo cascada rehegua". [Liñoitére oĩva]. Ojeguereko: https://en.wikipedia.org/wiki/Sequence_Diagram [125] Wikipedia, "Estrategia (patrón diseño)." [Liñoitére oĩva].
ANEXOS
Definition of Done
Team Capacity
Plantilla para la retrospectiva
Criterio de Ready
Prototipos de la solución
Entregables definidos para Pyxis
Vista lógica y Comportamiento
Como se puede observar en el diagrama anterior, la lógica de la plataforma se basa en las relaciones con la entidad OpenSpace, que es el objeto inicial. Luego, durante el plazo establecido para presentar las propuestas, los usuarios de la plataforma las registran y se relacionan con la abierta. Como se puede observar, la responsabilidad de organizar las propuestas está separada tanto de la Agenda como de la propia Propuesta.
Revisiones
Este punto se aplica a todos los diagramas, ya que facilita al lector identificar más aspectos de la solución de un vistazo. En cuanto a la información mostrada en el sistema para la demostración, se propuso presentar, en la medida de lo posible y en consulta con el cliente, datos reales de un evento, para mostrar el potencial de la plataforma. También se indicó que se debería ampliar la duración de la manifestación ya que parecía un poco corta en relación al resto de la presentación.
Riesgos
Plan de acción: Definir las reuniones a realizar desde el inicio, en caso de que las haya. Plan de acción: Definir estándares a seguir, como codificación, calidad, integración de código, versionado, etc. Plan de acción: Estimar cuanto antes el resto de historias de usuario que no tienen estimación y calcular qué velocidad debemos tener capaz de terminarlos.
Resultado del análisis heurístico
No se indicó claramente en qué campos estaba el error al crear un espacio abierto. Las fechas en las que se crea un espacio abierto y en las que se muestra en la lista no tienen el mismo formato. Los mensajes de error que se muestran en la aplicación al usuario son muy genéricos, no ayudan a comprender por qué ocurrió el error.
Escenarios de prueba
Una vez que el usuario está en la pantalla del panel, puede crear plantillas desde esta vista. Entonces: al acceder a la pantalla de OpenSpace, los sistemas abiertos deben mostrarse separados en dos tablas: actuales y no actuales. 11 Dado: El administrador creador accede a la lista desplegable Cuándo: Ver la lista desplegable del sistema.
Git branching model
