A partir de 2024 hay un único documento entregable del proyecto final de grado con el contenido explicado en este documento, tanto para los proyectos de ingeniería como para el componente de construcción de los proyectos de emprendimiento ‑excluye los proyectos de investigación y de extensión‑.
El documento entregable tiene un capítulo para cada una de las dimensiones del proyecto:
-
Requerimientos
-
Diseño y arquitectura
-
Desarrollo
-
Aseguramiento de la calidad
-
UX/UI
-
Gestión y proceso
El contenido de cada uno de esos capítulos —y de las secciones dentro de los capítulos— está explicado a continuación. El documento entregable tiene siempre todos estos capítulos, que van a completar y modificar en las sucesivas entregas a medida que avanza el proyecto.
Important
Dentro de cada una de las secciones, encontrarán dos tipos de etiquetas —o, tags— que marcan la obligatoriedad de cada parte.
1.1 Requerimientos
Basado en la plantilla de requerimientos utilizada en el curso de Análisis y diseño de aplicaciones I. Incluye aspectos del documento de casos de uso de ediciones del proyecto anteriores a 2024.
Basado en los conceptos del curso de Análisis y diseño de aplicaciones II. Incluye aspectos del documento de notas de arquitectura y diseño de ediciones del proyecto anteriores a 2024.
Basado en los conceptos del curso de Ingeniería de software. Incluye aspectos del documento de casos de prueba de ediciones del proyecto anteriores a 2024.
1.4 UX/UI
Basado en los conceptos del curso de Análisis y diseño de aplicaciones I.
1.5 Gestión
Basado en los conceptos del curso de Ingeniería de software.
Este documento describe aspectos metodológicos de los proyectos de finales de grado. La metodología ha evolucionado y a partir de 2024 combina algunos aspectos del marco metodológico que usábamos anteriormente con otros de metodologías ágiles actuales.
La metodología actual está basada en el enfoque Disciplined Agile® Delivery ‑DAD‑ del Project Management Institute. La elección de esta metodología se justifica en que es parte del curso de Gestión de proyectos ‑por un lado‑, y en que aborda todos los aspectos del ciclo de vida completo de un proyecto como los de final de grado, admitiendo múltiples formas de trabajo, abarcando todos los aspectos del desarrollo ágil de software de una manera sólida, pragmática y gobernable ‑por otro‑.
El ciclo de vida del DAD tiene tres fases, donde se construye gradualmente una solución consumible a lo largo del tiempo:
-
Inicio ‑o inception‑
-
Construcción
-
Transición
Cada una de estas fases puede tener una o más iteraciones o sprints.
Figura 1: Una vista de alto nivel del ciclo de vida de la entrega en DAD. Tomado de PMI.
Tip
Pueden ver las actividades en cada una de las fases de DAD en el DA Browser.
El anteproyecto y proyecto final de grado tienen las siguientes etapas, donde algunas de ellas tienen una entrega formal en webasignatura, según se indica más adelante:
-
Anteproyecto
-
Descubrimiento e inicio
-
Prueba de concepto
-
Primer release
-
Segundo release
-
Delivery al cliente y tercer release
Las siguientes son las diferentes dimensiones en las que los equipos trabajan a lo largo del proyecto; en algunas etapas trabajan más en una dimensión que en otras.
-
Requerimientos
-
Diseño y arquitectura
-
Desarrollo
-
Aseguramiento de la calidad
-
UX/UI
-
Gestión y proceso
De la combinación entre las etapas y las dimensiones surgen las actividades y los productos que se generan a lo largo del proyecto final de grado, como se detalla más adelante.
A continuación detallamos la correspondencia entre las etapas y entregas del proyecto final de grado con las fases de DAD.
Las etapas en el proyecto final de grado sirven para organizar el trabajo del proyecto; más adelante les mostramos qué actividades esperamos que realicen en cada etapa. Las entregas son instancias formales donde presentan el avance del trabajo en webasignatura y reciben feedback de su tutor; también les mostramos más adelante qué contenidos deberían entregar. Tengan en cuenta que las entregas de proyecto ocurren al final de las etapas incluidas en la entrega.
Una parte de las actividades que en DAD ocurren en la fase de inicio tienen lugar en el anteproyecto, mientras que otras tienen lugar en la etapa de descubrimiento e inicio del proyecto. El resto de las etapas del proyecto corresponden a la fase de construcción en DAD, excepto la última etapa, que incluye actividades que en DAD corresponden a construcción —tercer release— pero también eventualmente actividades de la fase de transición —delivery al cliente—.
Important
Las actividades de migración y puesta en producción incluidas en la fase de transición de DAD no suelen ser parte de los proyectos finales de grado; otras actividades, como capacitación, eventualmente sí pueden estar contempladas.
La etapa de anteproyecto es un tanto peculiar porque ocurre antes del comienzo formal del proyecto final de grado, aunque la incluimos aquí porque es una parte importante de todo el proceso. En esta etapa deben elegir o proponer su proyecto, y formular y presentar la correspondiente propuesta.
Para ello deberán mantener reuniones con la contraparte del proyecto, es decir, quién actúe como cliente. Esperamos que se familiaricen lo suficiente con la necesidad que les planteen y con el dominio del problema o del área de trabajo, como para formular la propuesta; pueden ver aquí qué contiene la propuesta a entregar al final de esta etapa.
También deberán determinar qué es lo que se necesita construir para resolver la necesidad planteada, incluyendo posibles soluciones arquitectónicas de alto nivel.
Aunque el anteproyecto está organizado como un curso, es sólo a efectos de saber quiénes están trabajando en una propuesta de proyecto y tener una webasignatura con:
-
La lista de proyectos disponibles propuestos por empresas u otras entidades.
-
Un foro para consultas y armado de equipos de proyecto entre los propios estudiantes.
-
Una tarea para la entrega de propuestas de proyecto; la fecha de entrega es la fecha límite para presentación de propuestas.
Para la inscripción a este curso, consulta la web de la carrera.
El contenido esperado de esta etapa para cada dimensión son los siguientes:
-
Requerimientos. Los eventos de negocio más significativos. Incluyan para cada evento del negocio al menos su descripción, sus datos, y si es de entrada o de salida.
Los caso de uso del negocio para cada evento del negocio identificado en el punto anterior. Del caso de uso del negocio incluyan al menos su descripción, el evento del negocio que lo activa, el actor o parte interesada ‑stakeholder‑ activa, y el resultado ‑outcome‑.
-
Diseño y arquitectura. Una arquitectura de alto nivel tentativa que define qué tipo de solución van a desarrollar en el proyecto: una aplicación web cliente‑servidor con una base de datos relacional, o una aplicación mobile con un backend REST y un back-office web con una base de datos no-relacional, o una aplicación de escritorio distribuida con una base de datos centralizada, etc.
-
Desarrollo. No es necesario que desarrollen código en esta etapa.
-
Aseguramiento de la calidad. Pueden usar la rúbrica de propuestas de proyecto final de grado para evaluar el producto que van a entregar; sin embargo, no es necesario que entreguen esta evaluación.
-
UX/UI. En caso de que el cliente indique que deben seguir ciertos estándares, mantener cierto estilo, seguir manuales de marca, etc. deben indicarlo aquí.
-
Gestión y proceso. Cuál de las seis versiones de ciclos de vida de DAD usarán en el proyecto y qué roles tendrá cada miembro del equipo.
La etapa de descubrimiento e inicio es la primera del proyecto. Dura entre tres y cuatro semanas.
Los objetivos en esta etapa son:
-
Terminar de familiarizarse con el dominio del problema; tuvieron su primer acercamiento cuando formularon la propuesta, ahora deberán completar su entendimiento del dominio del problema.
-
Completar los eventos del negocio y los casos de uso del negocio; la mayoría ya los identificaron para la propuesta durante el anteproyecto.
-
Armar un EDT ‑o WBS‑ incluyendo el MVP y un listado de épicas para el alcance todo el proyecto; este será el plan del proyecto.
-
Compartir con el cliente el plan del proyecto y validar expectativas sobre el alcance del proyecto y las soluciones arquitectónicas que incluyeron oportunamente en la propuesta de proyecto ‑si no lo hubieran hecho todavía‑.
-
Comenzar a escribir el documento entregable; pueden ver a continuación qué productos se generan en esta etapa para cada dimensión del proyecto.
Los productos esperados de esta etapa para cada dimensión son los siguientes:
-
Requerimientos. Todos los eventos del negocio; incluyan para cada evento de negocio al menos la misma información que incluyeron en la propuesta.
Todos los casos de uso del negocio para los eventos del negocio identificados; incluyan para cada caso de uso la misma información que incluyeron en la propuesta ‑más el resultado esperado, como se indica más adelante en la dimensión de aseguramiento de la calidad‑.
-
Diseño y arquitectura. Actualización de la arquitectura presentada en la propuesta, si corresponde; en caso de que haya cambios significativos —pasaron de una aplicación web a una aplicación mobile, por ejemplo—, incluyan una justificación.
-
Desarrollo. Aunque no es requerido, sí es recomendable tener un esqueleto de la arquitectura de la solución en código. Por ejemplo, si el producto final será una aplicación mobile con un backend, pueden tener un servicio web REST para el backend con un endpoint de chequeo de salud1 que retorne siempre
200 OKy el cliente mobile puede ser simplemente una pantalla de bienvenida que muestre el resultado del chequeo de salud del backend, todo corriendo en ambiente de desarrollo. Aunque esto pueda cambiar en el futuro, les obligará a crear los proyectos, ponerlos en un repositorio de control de configuración en línea, asignar los permisos, etc.
Important
Todos los miembros del equipo, independientemente de su rol, deberán conocer y estar en condiciones de ejecutar el código desarrollado a lo largo de todo el proyecto.
-
Aseguramiento de la calidad. Completen la sección de resultado esperado de cada caso de uso, y asegúrense de que es verificable.
Definan también la estrategia de pruebas tal como se indica en la sección de aseguramiento de la calidad.
Pueden usar la rúbrica de la primera entrega para evaluar lo que hayan avanzado del producto que van a entregar, teniendo en cuenta que hay otras etapas por completar antes de esa entrega. No es necesario que entreguen esta evaluación.
-
UX/UI. Actualización de la información presentada en la propuesta, si corresponde. En caso de que haya cambios significativos, incluyan una justificación.
-
Gestión. Definición de herramientas para la operativa cotidiana del proyecto, por ejemplo:
Gestión del backlog. Recomendamos usar Azure Devops Services ya que tienen acceso a la versión completa de esta herramienta con la cuenta de estudiante @correo.ucu.edu.uy; pero en acuerdo con tu tutor pueden usar otras2.
Repositorio de código. Habitualmente usamos GitHub y los estudiantes pueden tener repositorios privados en la organización de la universidad. Pídanle a su tutor que les gestione la creación de los repositorios que necesiten.
Repositorio de documentos. Pueden usar también Microsoft Teams para esto; nuevamente, si lo acuerdan con su tutor, pueden usar otros2.
Videoconferencia ‑para reuniones remotas con el equipo y ocasionalmente con su tutor; las clases son presenciales‑. Recomendamos usar Microsoft Teams, que es la herramienta elegida por la universidad para colaboración, pero en acuerdo con su tutor, pueden usar otras2.
La segunda etapa del proyecto es la prueba de concepto. Dura entre tres y cuatro semanas.
Los objetivos de esta etapa son:
-
Relevar y especificar los casos de uso del producto para los casos de uso del negocio más significativos que serán parte del MVP.
-
Usando la plantilla de requerimiento atómico especificar la versión inicial de los requerimientos funcionales y no funcionales de los casos de uso del producto.
Pueden usar historias de usuario para especificar los requerimientos.
-
Actualizar el plan de pruebas y agregar los casos de prueba en aquellos casos que sea posible.
-
Definir la arquitectura detallada y las tecnologías que van a utilizar.
-
Implementar la mínima cantidad de requerimientos ‑puede ser uno‑ que permita validar la arquitectura planteada.
-
Actualizar el plan de proyecto ajustando el EDT ‑WBS‑ y asignando requerimientos a los releases de las próximas entregas.
Pueden usar épicas en el plan de proyecto y asignarlas a los releases de las próximas entregas.
-
Compartir con el cliente el plan del proyecto ajustado y obtener retroalimentación del cliente.
Los productos esperados de esta etapa para cada dimensión son los siguientes:
-
Requerimientos. Los casos de uso del producto para los casos de uso del negocio más significativos identificados en la etapa anterior. Incluyan en cada caso de uso del producto al menos su disparador, su nombre, el actor, el curso básico y el resultado esperado; excepto para el o los casos de uso del producto que hayan elegido para validar la arquitectura, que tendrán que estar completos.
Los requerimientos funcionales y no funcionales para el o los casos de uso del producto que hayan incluido.
-
Diseño y arquitectura. La arquitectura detallada y las tecnologías que van a utilizar para cada componente.
-
Desarrollo. El código funcionando que implementa el o los requerimientos que hayan escogido para validar la arquitectura. Incluyan instrucciones para que su tutor pueda ejecutar la solución en un ambiente de desarrollo.
-
Aseguramiento de la calidad. Los casos de prueba en los casos en que sea posible y pruebas de unidad para el código entregado si fuera parte de la estrategia de pruebas.
-
UX/UI. Maquetas para la interfaz de usuario del o de los casos de uso elegidos para validar la arquitectura.
-
Gestión. El plan de proyecto actualizado y los siguientes indicadores o reportes de métricas a lo largo de la etapa3:
Velocidad. La capacidad del equipo de entregar trabajo. El propósito de este indicador es mostrar cuánto trabajo tuvo capacidad de entregar el equipo durante la etapa.
Burn down. La evolución de la cantidad de trabajo entregada. El propósito de este indicador es mostrar la cantidad de trabajo realizada por el equipo durante la etapa.
Cumulative flow. La evolución de la cantidad de trabajo pendiente, en progreso y terminada. El propósito de este indicador es entender si hubo scope creep, demoras en completar items, etc. durante la etapa.
Build status. La evolución del estado de compilación de la solución. El propósito de este indicador es ver si hubo contribuciones que introdujeron inestabilidad en la solución.
Test failures. La evolución del estado de los casos de prueba. El propósito de este indicador es entender cómo agregan casos de prueba a lo largo del tiempo, y cómo la solución pasa o no estos casos de prueba.
La tercera etapa del proyecto es el primer release. Dura entre doce y catorce semanas.
Más allá de que en cada iteración produzcan una solución consumible, en el primer release sí o sí deberías tener una solución similar a la final, aunque obviamente sólo implementará los requerimientos asignados a esta etapa. Excepto por el hecho de que no es una solución funcionalmente completa, debería tener las siguientes características:
-
Lo que está implementado es usable
-
Lo que entregas tiene alta calidad
-
La documentación para el usuario está actualizada
Los objetivos de esta etapa son:
-
Actualizar los componentes de diseño y arquitectura del documento entregable.
-
Refinar el EDT ‑o WBS‑.
-
Liberar una primera versión del MVP funcionando.
De nuevo, aunque en cada iteración ya vengan usando una forma de compilación, despliegue y prueba automatizada, en este release sí o sí deberás tenerla. Esto puede ser implementado con GitHub Actions, Azure Pipelines, o alguna otra herramienta equivalente.
Los productos esperados de esta etapa para cada dimensión son los siguientes:
-
Requerimientos. Los casos de uso del producto completos que correspondan a la funcionalidad incluida en esta etapa; las actualizaciones de los previamente entregados si correspondiera.
Los requerimientos atómicos completos correspondientes a la funcionalidad incluida en esta etapa; las actualizaciones que correspondiera de los que hayan entregado antes.
-
Diseño y arquitectura. Los diagramas de despliegue completos. Los diagramas de clases al menos con las clases del dominio. En caso de que corresponda, otros diagramas de actividades o secuencia.
-
Desarrollo. El código funcionando que implementa requerimientos que hayan implementado en este etapa. Nuevamente incluyan instrucciones para que su tutor pueda ejecutar la solución en un ambiente de desarrollo.
-
Aseguramiento de la calidad. Las pruebas de unidad para el código entregado.
Casos de prueba para los casos de uso del producto incluidos en esta fase. Datos de prueba para esos casos de prueba. Resultados de esas pruebas.
En caso de que corresponda, pruebas de carga para mostrar el funcionamiento correcto de la arquitectura.
-
UX/UI. Maquetas para los casos de uso del producto incluidos en esta etapa.
-
Gestión. El plan de proyecto actualizado y los mismos indicadores de la etapa anterior.
La cuarta etapa del proyecto es el segundo release. Dura entre dieciocho y veinte semanas.
Los objetivos de esta etapa son:
-
Conseguir retroalimentación del cliente respecto del MVP.
-
Liberar una segunda versión del MVP funcionando, con la UX/UI avanzada, y al menos tres funcionalidades definidas por el cliente como nice to have implementadas.
Aunque no es obligatorio, recomendamos definir la interfaz de usuario con herramientas de creación de prototipos como Figma, para validar con el cliente antes de la implementación en la solución.
-
Definir el criterio de ajuste ‑o criterio de aceptación‑ de todos los requerimientos atómicos especificados.
-
Completar la sección de calidad del documento entregable.
-
Actualizar las secciones de arquitectura y diseño si corresponde.
-
Obtener y presentar evidencia del feedback del cliente y los próximos pasos definidos en acuerdo con él.
-
Revisar la gestión del proyecto, con métricas de proceso y puntos de mejora encontrados, desvíos y cómo los gestionaron.
Los productos esperados de esta etapa para cada dimensión son los siguientes:
-
Requerimientos. Los casos de uso del producto completos que corresponden a las funcionalidades incluidas en esta etapa; incluyan actualizaciones de los previamente entregados si corresponde.
Los requerimientos atómicos completos correspondientes a las funcionalidades incluidas en esta etapa; incluyan actualizaciones de los previamente entregados si corresponde.
-
Diseño y arquitectura. Los diagramas de despliegue actualizados. Los diagramas de clases con todas las clases para las funcionalidades incluidas en esta etapa. En caso de que corresponda, diagramas de actividades o secuencia.
-
Desarrollo. El código funcionando que implementa los requerimientos que hayan incluido en esta etapa, incluyendo instrucciones para ejecutar la solución en ambiente de desarrollo.
-
Aseguramiento de la calidad. Las pruebas de unidad para el código entregado.
Actualización de los casos de prueba entregados en la etapa anterior. Pruebas de regresión utilizando esos casos de prueba actualizados.
Casos de prueba de usuario final para los casos de uso del producto incluidos en esta etapa. Datos de prueba para esos casos de prueba. Resultados de esas pruebas.
-
UX/UI. Maquetas para los casos de uso del producto incluidos en esta etapa.
-
Gestión. El plan de proyecto actualizado y los mismos indicadores de las etapas anteriores.
Esta es la quinta y última etapa del proyecto. Dura entre tres y cuatro semanas.
Los productos esperados de esta etapa para cada dimensión son los siguientes:
-
Requerimientos. Los casos de uso del producto completos para toda la solución.
Los requerimientos atómicos completos para toda la solución.
-
Diseño y arquitectura. Los diagramas de despliegue completos. Los diagramas de clases completos, al menos con las clases del dominio; idealmente incluir otras clases relevantes de la solución, excluyendo clases de frameworks o generadas por herramientas. Diagramas de actividades o de secuencia si corresponde.
-
Desarrollo. El código completo de la solución.
El pipe de CI/CD actualizado para despliegue en ambientes de pruebas.
-
Aseguramiento de la calidad. Las pruebas de unidad para el código entregado.
Pruebas de integración para un conjunto significativo de la funcionalidad de la solución. Datos de prueba para esas pruebas. Resultados de esas pruebas.
Casos de prueba de usuario final para un conjunto significativo de la funcionalidad de la solución. Datos de prueba para esas pruebas. Resultados de esas pruebas.
-
UX/UI. No es necesario incluir nuevas maquetas en esta etapa.
-
Gestión. El plan de proyecto actualizado y los mismos indicadores de la etapa anterior.
Retrospectiva.
Notas generales relativas a la propuesta:
-
Deberá tener un mínimo de 10 páginas y un máximo de 20.
-
Deberá ser entregada en formato PDF.
-
Deberá ser entregada vía webasignatura.
-
Deberá ser firmada por todos los integrantes del grupo.
Contenido de la propuesta:
-
Descripción de los integrantes del grupo, junto con su historial laboral y competencias claves dentro del proyecto.
-
Borrador del propósito del proyecto
-
Interesados preliminares y borrador de sus necesidades clave. En particular identificar quién de los interesados actuará como encargado del proyecto de la contraparte y quién hace las veces de patrocinador.
-
El producto de la etapa de anteproyecto descrita antes. Esto se ve resumido en la siguiente tabla:
| Requerimientos | Eventos de negocio más significativos | Casos de uso del negocio para los eventos de negocio | Requerimientos relacionados a UX/UI |
| Diseño y Arquitectura | Arquitectura tentativa a alto nivel | ||
| Desarrollo | No aplica | ||
| Aseguramiento de la Calidad | No aplica | ||
| UX/UI | No aplica | ||
| Gestión y Proceso | Versión de DAD a usar y roles de los miembros del equipo |
-
Carta de confidencialidad o Compromiso de confidencialidad según corresponda.
-
Documento entregable, con el contenido indicado para las etapas descubrimiento e inicio, prueba de concepto y primer release. La siguiente tabla resume lo agregado al documento para esta entrega:
| Requerimientos | Todos los eventos del negocio | Los casos de uso del negocio de las funcionalidades implementadas hasta la fecha | Los casos de uso del producto correspondientes a las funcionalidades implementadas y requerimientos atómicos para los casos de uso implementados |
| Diseño y Arquitectura | Arquitectura detallada con tecnologías usadas por cada componente | Diagramas de despliegue, de clases y cualquier otro pertinente para lo desarrollado completos | En caso de que hayan habido cambios a la arquitectura propuesta inicialmente, justificación de los mismos |
| Desarrollo | Código funcionando con lo implementado hasta el momento | Instrucciones para ejecutar la aplicación en entorno de desarrollo | |
| Aseguramiento de la Calidad | Tests unitarios para las funcionalidades desarrolladas | Si corresponde, pruebas de carga para validar la arquitectura | |
| UX/UI | Maquetas de UX/UI para las funcionalidades desarrolladas | ||
| Gestión y Proceso | Versión de DAD utilizada y roles de los miembros del equipo | Herramientas de gestión del proyecto utilizadas en su cotidianidad | Plan del proyecto actualizado e indicadores del proceso hasta el momento (velocidad, burn down, cumulative flow, build status, test failures, etc.) |
- Documento entregable, con el contenido indicado para la etapa de segundo release. La siguiente tabla resume lo agregado al documento para esta entrega:
| Requerimientos | Todos los eventos del negocio | Los casos de uso del negocio de las funcionalidades implementadas hasta la fecha | Los casos de uso del producto correspondientes a las funcionalidades implementadas y requerimientos atómicos para los casos de uso implementados | |
| Diseño y Arquitectura | Arquitectura detallada con tecnologías usadas por cada componente | Diagramas de despliegue, de clases y cualquier otro pertinente para lo desarrollado completos | En caso de que hayan habido cambios a la arquitectura propuesta inicialmente, justificación de los mismos | |
| Desarrollo | Código funcionando con lo implementado hasta el momento | Instrucciones para ejecutar la aplicación en entorno de desarrollo | ||
| Aseguramiento de la Calidad | Tests unitarios para las funcionalidades desarrolladas | Si corresponde, pruebas de carga para validar la arquitectura | Pruebas de regresión | Casos de prueba de usuario final para los casos de uso del producto implementados hasta el momento, incluyendo los datos de prueba utilizados y los resultados de las pruebas |
| UX/UI | Maquetas de UX/UI para las funcionalidades desarrolladas | |||
| Gestión y Proceso | Versión de DAD utilizada y roles de los miembros del equipo | Herramientas de gestión del proyecto utilizadas en su cotidianidad | Plan del proyecto actualizado e indicadores del proceso hasta el momento (velocidad, burn down, cumulative flow, build status, test failures, etc.) |
-
Documento entregable, con el contenido indicado para la etapa de delivery al cliente y tercer release. La siguiente tabla resume lo agregado al documento para esta entrega:
| Requerimientos | Todos los eventos del negocio | Todos los casos de uso del negocio | Los casos de uso del producto y requerimientos atómicos para toda la solución | |
| Diseño y Arquitectura | Arquitectura detallada con tecnologías usadas por cada componente | Diagramas de despliegue, de clases y cualquier otro pertinente para lo desarrollado completos | En caso de que hayan habido cambios a la arquitectura propuesta inicialmente, justificación de los mismos | |
| Desarrollo | Código completo de la solución | Pipeline de CI/CD actualizado para despliegue en ambiente de pruebas | ||
| Aseguramiento de la Calidad | Tests unitarios para el código entregado | Si corresponde, pruebas de carga para validar la arquitectura | Pruebas de regresión | Casos de prueba de usuario final y pruebas de integración, ambos para un conjunto significativo de la funcionalidad de la solución, incluyendo los datos de prueba utilizados y los resultados de las pruebas |
| UX/UI | Maquetas de UX/UI para las funcionalidades desarrolladas | |||
| Gestión y Proceso | Versión de DAD utilizada y roles de los miembros del equipo | Herramientas de gestión del proyecto utilizadas en su cotidianidad | Plan del proyecto actualizado e indicadores del proceso hasta el momento (velocidad, burn down, cumulative flow, build status, test failures, etc.) | Retrospectiva |
- Presentación oral de 15 minutos, evaluada según rúbrica de la defensa
Footnotes
-
Ese endpoint será la semilla para implementar en el futuro el patrón Health Endpoint Monitoring por ejemplo. ↩
-
Tengan en cuenta la seguridad y privacidad de la información que almacenen en estos repositorios; si tienen un acuerdo de confidencialidad con el cliente, deberían usar las herramientas recomendadas. También deberán considerar que otras herramientas pueden tener costos asociados o limitar la cantidad de usuarios o de archivos en las versiones gratuitas. ↩ ↩2 ↩3
-
Estos reportes pueden ser generados automáticamente con la herramienta Azure DevOps recomendada, no tienen porqué hacerlos a mano si la usan para la gestión del proyecto. Otras herramientas también pueden generarlas. ↩