# 1 Entregable del proyecto
## Introducción
<!-- TODO: circular con Bernie; involucrar a Danielli; completar duración; -->
A partir de 2026 hay un único documento entregable del [proyecto final de
grado](https://webasignatura.ucu.edu.uy/course/view.php?id=7559) 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‑.
Ese documento entregable tiene un capítulo para cada una de las
dimensiones del proyecto:
* **Requerimientos**. Basado principalmente en los procesos y plantillas de
relevamiento y especificación de requerimientos utilizadas 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. Vean el detalle de esta
dimensión [aquí](./1_1_.Requerimientos.md).
* **Diseño y arquitectura**. Basado principalmente en los procesos y plantillas
utilizadas 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. Vean el detalle de esta dimensión
[aquí](./1_2_.Diseno_y_arquitectura.md).
* **Desarrollo**. Es la única dimensión que **no** es parte del documento, pues
el código reside en un repositorio. Lo que **sí** deben incluir en el
documento es un vínculo a el o los repositorios utilizados.
* **Aseguramiento de la calidad**. Basado principalmente 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. Vean el detalle de esta
dimensión [aquí](./1_3__Aseguramiento_de_la_calidad.md).
* **UX/UI**. Basado en los conceptos y herramientas de diseño de experiencia e
interfaz de usuario principalmente del curso de Análisis y diseño de
aplicaciones I. Vean el detalle de esta dimensión [aquí](./1_4_UX_UI.md).
* **Gestión y proceso**. Basado en los conceptos principalmente de los cursos de
Ingeniería de software y Gestión de Proyectos. Vea el detalle de esta
dimensión [aquí](./1_5_.Gestion_y_proceso.md).
El documento entregable con esos capítulos se construye progresivamente durante
las etapas del proyecto:
* **Anteproyecto**. La etapa de anteproyecto es un tanto peculiar porque
ocurre antes del comienzo formal del proyecto final de grado; 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. Vean el detalle de esta etapa [aquí](#anteproyecto).
* **Descubrimiento e inicio**. Es la primera etapa del proyecto, en la que
terminan de familiarizarse con el dominio del problema, planifican las
actividades para el resto del proyecto, comparten el plan y validan
expectativas con el cliente, arman el esqueleto de la solución y los
repositorios, y comienzan a escribir el documento entregable. Vean el detalle
de esta etapa [aquí](#descubrimiento-e-inicio).
* **Prueba de concepto**. Es la segunda etapa del proyecto, en la que
especifican y construyen un MVP, y obtienen retroalimentación del cliente para
confirmar —de forma temprana— que el proyecto avanza en la dirección correcta.
Vean el detalle de esta etapa [aquí](#prueba-de-concepto).
* **Primer *release***. Es la tercera etapa del proyecto, al final de la cual
harán la **primera entrega** formal de lo que llevan construido tanto al
cliente como su tutor. Vean el detalle de esta etapa [aquí](#primer-release).
* **Segundo *release***. Es la cuarta etapa del proyecto, al final de la cual
harán la **segunda entrega** preliminar formal de lo que llevan construido
tanto al cliente como a su tutor. Vean el detalle de esta etapa
[aquí](#segundo-release).
* ***Delivery* completo**. Es la última etapa del proyecto, que culmina habiendo
completado las entregas tanto al cliente como el tribunal. Vean el detalle de
esta etapa [aquí](#delivery-completo).
Este documento no constituye una guía detallada. Pueden consultar las
referencias mencionadas [más
adelante](#correspondencia-entre-el-marco-metodológico-y-el-proyecto-final-de-grado)
para obtener más detalles tanto de las dimensiones del documento como de las
actividades en las etapas del proyecto.
## Resumen
Aquí resumimos el contenido del documento a entregar durante el [proyecto
final de grado](https://webasignatura.ucu.edu.uy/course/view.php?id=7559); hay
más detalles más adelante en este mismo documento.
<style>
table td, table th {
vertical-align: top;
}
.vertical-text {
writing-mode: vertical-lr;
}
</style>
<table>
<tr>
<th style="width:5%">
Entrega
</th>
<th style="width:5%">
Etapa
</th>
<th style="width:15%">
Requerimientos
</th>
<th style="width:15%">
Diseño y arquitectura
</th>
<th style="width:15%">
Desarrollo
</th>
<th style="width:15%">
Aseguramiento de la calidad
</th>
<th style="width:15%">
UX/UI
</th>
<th style="width:15%">
Gestión
</th>
</tr>
<tr>
<td class="vertical-text">
<a href="#propuesta-de-proyecto">Propuesta de proyecto</a>
</td>
<td class="vertical-text">
<a href="#anteproyecto">Anteproyecto</a>
</td>
<td>
Los detalles completos de los eventos del negocio más significativos. Los
detalles más importante de esos casos de uso del negocio para esos eventos
del negocio. Estimación del tamaño de los datos y de cantidad de eventos.
</td>
<td>
La arquitectura de alto nivel tentativa.
</td>
<td>
No aplica.
</td>
<td>
Asegúrense de que cumpla con la rúbrica de propuestas.
</td>
<td>
Los estándares o manuales de marca que deban seguir, si los hubiera.
</td>
<td>
El ciclo de vida a utilizar en el proyecto.
</td>
</tr>
<tr>
<td rowspan=3 class="vertical-text">
<a href="#primera-entrega">Primera entrega</a>
</td>
<td class="vertical-text">
<a href="#descubrimiento-e-inicio">Descubrimiento e inicio<a>
</td>
<td>
<!-- A los eventos del negocio más significativos le agrega todos los
eventos del negocio. A los casos de uso del negocio de esos eventos del
negocio le agrega el resultado esperado. -->
Los detalles completos de todos los eventos del negocio. Los detalles más
importantes —incluyendo el resultado esperado— de todos los casos de uso
del negocio.
</td>
<td>
<!-- Lo mismo excepto si hay cambios. -->
Actualización de la arquitectura, si corresponde; si hay cambios, incluyan
una justificación.
</td>
<td>
<!-- Esqueleto de la arquitectura en código. -->
Recomendamos tener el esqueleto de la arquitectura en código.
</td>
<td>
<!-- Agrega resultados verificables en los casos de uso del negocio. -->
Completen la sección de resultado esperado de los casos de uso del negocio
y asegúrense de que es verificable.
</td>
<td>
<!-- Lo mismo excepto si hay cambios. -->
Actualización de la información presentada en la propuesta, si
corresponde; si hay cambios, incluyan una justificación.
</td>
<td>
<!-- Agrega herramientas a utilizar. -->
Definición del conjunto de herramientas a utilizar en el proyecto para
llevar el <i>backlog</i>, los repositorios de código y de documentos,
videoconferencia, etc.
</td>
</tr>
<tr>
<td class="vertical-text">
<a href="#prueba-de-concepto">Prueba de concepto</a>
</td>
<td>
<!-- Agrega casos de uso del producto para prueba de concepto y
requerimientos atómicos funcionales y no-funcionales. -->
Los detalles más importantes de los casos de uso del producto para los
casos de uso del negocio en los que tiene más sentido hacer una prueba de
concepto. Los detalles más importantes de los requerimientos atómicos
funcionales y no-funcionales derivados de esos casos de uso. Esos
requerimientos atómicos deben ser requerimientos más arquitectónicamente
significativos.
</td>
<td>
<!-- Agrega particiones de primer nivel de la arquitectura y tecnologías
a utilizar. -->
La arquitectura detallada —incluyendo al menos las particiones de primer
nivel— que satisface los requerimientos que hayan elegido para la prueba
de concepto y las tecnologías a utilizar.
</td>
<td>
<!-- Agrega código funcionando y pipelines de despliegue. -->
El código funcionando que implementa los requerimientos que hayan elegido
e instrucciones para que terceros pueda ejecutar la aplicación en un
ambiente diferente al del equipo de proyecto. Los <i>pipelines</i> para
probar, generar, integrar y desplegar automáticamente el código.
</td>
<td>
<!-- Agrega casos de prueba. -->
Los casos de prueba que demuestren que el código entregado satisface los
requerimientos atómicos que hayan elegido para la prueba de concepto.
</td>
<td>
<!-- Agrega maquetas. -->
Las maquetas para la interfaz de usuario de los casos de uso del producto
que hayan elegido.
</td>
<td>
<!-- Agrega indicadores. -->
El plan de proyecto actualizado y los siguientes indicadores o reportes de
métricas: velocidad, <i>burn down</i>, <i>cumulative flow</i>, <i>build
status</i> y <i>test failures</i>.
</td>
</tr>
<tr>
<td class="vertical-text">
<a href="#primer-release">Primer <i>release</i></a>
</td>
<td>
<!-- Agrega más detalles a los mismos casos de uso. -->
Los detalles completos de los casos de uso del producto para la
funcionalidad incluida en esta etapa y los requerimientos atómicos
funcionales y no-funcionales para esa funcionalidad.
</td>
<td>
<!-- Agrega diagramas de componentes y despliegue, clases y opcionalmente
actividades y secuencia. -->
Los diagramas de componentes y de despliegue completos; diagramas de
clases al menos de las clases de dominio; diagramas de actividades y de
secuencia cuando corresponda.
</td>
<td>
<!-- Lo mismo. -->
El código funcionando de los requerimientos funcionales y no-funcionales
correspondientes a la funcionalidad incluida en esta etapa e instrucciones
actualizadas para que terceros puedan ejecutar la aplicación. Los
<i>pipelines</i> actualizados para probar, generar, integrar y desplegar
el código.
</td>
<td>
<!-- Agrega pruebas de unidad y otras pruebas para requerimientos
no-funcionales. -->
Las pruebas de unidad para el código entregado. Los casos de prueba para
los casos de uso del producto correspondientes a la funcionalidad incluida
en esta etapa. Otras pruebas para asegurar que el producto satisface los
requerimientos no-funcionales incluidos en esta etapa.
</td>
<td>
<!-- Lo mismo. -->
Las maquetas para los casos de uso del producto incluidos en esta etapa.
</td>
<td>
<!-- Lo mismo. -->
El plan de proyecto actualizado y los indicadores mencionados en la etapa
anterior y actualizados durante esta etapa.
</td>
</tr>
<tr>
<td class="vertical-text">
<a href="#segunda-entrega">Segunda entrega</a>
</td>
<td class="vertical-text">
<a href="#segundo-release">Segundo <i>release</i></a>
</td>
<td>
<!-- Lo mismo pero actualizado para el alcance de esta entrega. -->
Los casos de uso del producto completos para la funcionalidad incluida en
esta etapa y los requerimientos atómicos funcionales y no-funcionales para
esa funcionalidad.
</td>
<td>
<!-- Lo mismo pero actualizado para el alcance de esta entrega. -->
Los diagramas de componentes y despliegue actualizados; los diagramas de
clases actualizados de al menos las clases de dominio; los diagramas de
actividades y de secuencia cuando corresponda.
</td>
<td>
<!-- Lo mismo pero actualizado para el alcance de esta entrega. -->
El código funcionando de los requerimientos funcionales y no-funcionales
correspondientes a la funcionalidad incluida en esta etapa. Las
instrucciones actualizadas para que terceros puedan ejecutar la
aplicación. Los <i>pipelines</i> actualizados para probar, generar,
integrar y desplegar el código.
</td>
<td>
<!-- Lo mismo pero actualizado para el alcance de esta entrega. -->
Las pruebas de unidad para el código entregado. Los casos de prueba para
los casos de uso del producto correspondientes a la funcionalidad incluida
en esta etapa, incluyendo datos de prueba y resultado esperado de esas
pruebas. Otras pruebas para asegurar que el producto satisface los
requerimientos no-funcionales incluidos en esta etapa.
</td>
<td>
<!-- Lo mismo pero actualizado para el alcance de esta entrega. -->
Las maquetas para los casos de uso del producto incluidos en esta etapa.
</td>
<td>
<!-- Lo mismo pero actualizado para el alcance de esta entrega. -->
El plan de proyecto actualizado y los indicadores antes mencionados en la
etapa anterior y actualizados durante esta etapa.
</td>
</tr>
<tr>
<td class="vertical-text">
<a href="#entrega-final">Entrega final</a>
</td>
<td class="vertical-text">
<a href="#delivery-completo"><i>Delivery</i> completo</a>
</td>
<td>
<!-- Lo mismo pero actualizado para todo el alcance. -->
Los detalles completos de los casos de uso del producto y los
requerimientos atómicos funcionales y no-funcionales completos para toda
la solución.
</td>
<td>
<!-- Lo mismo pero actualizado para todo el alcance. -->
Los diagramas de componentes y de despliegue completos; los diagramas de
clases completos —al menos de las clases del dominio— idealmente de otras
clases relevantes de la solución. Los diagramas de actividades y de
secuencia, cuando corresponda.
</td>
<td>
<!-- Agrega pipelines para ambientes de prueba. -->
El código completo de la solución. Las instrucciones actualizadas para que
terceros —incluyendo el cliente— puedan ejecutar la aplicación. Los
<i>pipelines</i> actualizados de CI/CD para probar, generar, integrar y
desplegar el código en ambientes de prueba.
</td>
<td>
<!-- Agrega datos de prueba y resultados esperados de las pruebas. -->
Las pruebas de unidad para el código entregado; las pruebas de integración
para parte de la solución; datos de prueba y resultados de esas pruebas.
Los casos de prueba de usuario final para parte de la solución; los datos
de prueba y resultados de esas pruebas.
</td>
<td>
No es necesario incluir nuevas maquetas en esta etapa.
</td>
<td>
<!-- Agrega la retrospectiva del proyecto. -->
El plan de proyecto actualizado y los mismos indicadores de la etapa
anterior. Una retrospectiva reflexiva del proyecto.
</td>
</tr>
</table>
## Aspectos metodológicos
Esta sección 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](https://www.pmi.org/disciplined-agile/process/introduction-to-dad)
‑DAD‑ del [Project Management Institute](https://www.pmi.org). La elección de
esta metodología se justifica —por un lado— en que es parte del curso de Gestión
de proyectos, y —por otro— 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.
### El ciclo de vida DAD
El [ciclo de vida](https://www.pmi.org/disciplined-agile/lifecycle) 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*.
<span id="figura-1"/>
*Figura 1: Una vista de alto nivel del ciclo de vida de la entrega en DAD*.
Tomado de [PMI](https://www.pmi.org/disciplined-agile/lifecycle)
> [!TIP]
> Pueden ver las actividades en cada una de las fases de DAD en el [DA
> Browser](https://dabrowser.pmi.org).
<!-- cSpell:ignore webasignatura -->
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](#correspondencia-entre-el-marco-metodológico-y-el-proyecto-final-de-grado):
* Anteproyecto
* Descubrimiento e inicio
* Prueba de concepto
* Primer *release*
* Segundo *release*
* *Release* final
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.
### Correspondencia entre el marco metodológico y el proyecto final de grado
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](#etapas-del-proyecto-final-de-grado) 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](#entregas-del-proyecto-final-de-grado) qué contenidos deberían
entregar. Tengan en cuenta que las entregas de proyecto ocurren al final de las
etapas incluidas en la entrega.
<span id="figura-2"/>
*Figura 2: Correspondencia entre DAD y las etapas y entregables.*
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 ‑*release* final‑
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.
## Contenido
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.
>
> <img alt="REQUERIDO" src="https://img.shields.io/badge/REQUERIDO-FF4D4D" />:
> Todo lo indicado a continuación hasta la próxima etiqueta es de carácter
> obligatorio a efectos del entregable del proyecto.
>
> <img alt="SEGÚN PROYECTO"
> src="https://img.shields.io/badge/SEG%C3%9AN%20PROYECTO-FFD700" />: Todo lo
> indicado a continuación hasta la próxima etiqueta, **puede ser obligatorio** a
> efectos del entregable del proyecto dependiendo de las cualidades del
> producto. Para cada uno de los ítems englobados en esta etiqueta, se explica
> cuándo es de carácter obligatorio. Ante cualquier duda respecto a la
> obligatoriedad de estos ítems, pueden consultar al tutor.
1\. [Requerimientos](./1_1_.Requerimientos.md)
1.1\. [Impulsores del proyecto](./1_1_1_Impulsores_del_proyecto.md)
1.2\. [Restricciones del proyecto](./1_1_2_Restricciones_del_proyecto.md)
1.3\. [Requerimientos funcionales](./1_1_3_Requerimientos_funcionales.md)
1.4\. [Requerimientos no-funcionales](./1_1_4_Requerimientos_no_funcionales.md)
2\. [Diseño y arquitectura](./1_2_.Diseno_y_arquitectura.md)
3\. [Aseguramiento de la calidad](./1_3__Aseguramiento_de_la_calidad.md)
4\. [UX/UI](./1_4_UX_UI.md)
5\. [Gestión y proceso](./1_5_.Gestion_y_proceso.md)
## Etapas del proyecto final de grado
### Anteproyecto
Para elaborar la propuesta de anteproyecto 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](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Trabajo_y_area_de_trabajo.md), como para formular la
propuesta; pueden ver [aquí](#propuesta-de-proyecto) 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](https://webasignatura.ucu.edu.uy/course/view.php?id=6191) 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](https://webasignatura.ucu.edu.uy/course/view.php?id=3751).
<!-- TODO: llevar a la tabla de contenido por etapa -->
El contenido esperado de esta etapa para cada dimensión son los siguientes:
* **Requerimientos**. Los [eventos de
negocio](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Evento_del_negocio.md) 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](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Caso_de_uso_del_negocio.md) 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*‑.
Cantidades aproximadas u órdenes de magnitud de las entidades más importantes
y eventos más relevantes; esto debe dar una idea del tamaño de los datos y de
los eventos que gestionará la aplicación.
* **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](/2_Rubricas/2_1_Rubrica_propuesta.md) final de grado
para evaluar el documento 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](https://www.pmi.org/disciplined-agile/process/introduction-to-dad/full-delivery-lifecycles-introduction)
usarán en el proyecto y qué
[roles](https://www.pmi.org/disciplined-agile/process/introduction-to-dad/people-first-roles-in-dad-introduction)
tendrá cada miembro del equipo.
### Descubrimiento e inicio
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](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_EDT.md) ‑o [*WBS*](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_WBS.md)‑
incluyendo el [MVP](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_MVP.md) y un listado de
[épicas](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Epica.md) 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; tienen [más arriba](#resumen) el
resumen del contenido para cada dimensión en cada etapa y pueden ver a
continuación —y de ahora en adelante— el detalle de 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‑.
<!-- @fmachadopiriz ver qué más incluir del documento de visión, por ejemplo,
objetivo del proyecto; revisar con @PaoloMazza1204 -->
* **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 salud[^1] que retorne
siempre `200 OK` y 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](./1_3__Aseguramiento_de_la_calidad.md#estrategia-de-pruebas).
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](https://azure.microsoft.com/es-es/products/devops) 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 otras[^2].
**Repositorio de código**. Habitualmente usamos GitHub y los estudiantes
pueden tener repositorios privados en la
[organización](https://github.com/ucudal) 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](https://teams.microsoft.com) para esto; nuevamente, si lo acuerdan con
su tutor, pueden usar otros[^2].
**Videoconferencia** ‑para reuniones remotas con el equipo y ocasionalmente
con su tutor; las clases son presenciales‑. Recomendamos usar [Microsoft
Teams](https://teams.microsoft.com), que es la herramienta elegida por la
universidad para colaboración, pero en acuerdo con su tutor, pueden usar
otras[^2].
[^1]: Ese *endpoint* será la semilla para implementar en el futuro el patrón
[Health Endpoint
Monitoring](https://learn.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring)
por ejemplo.
[^2]: 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.
### Prueba de concepto
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](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Caso_de_uso_del_producto.md) para los casos de uso
del negocio más significativos que serán parte del MVP.
* Usando la [plantilla de requerimiento
atómico](https://github.com/ucudal/ANDIS_Conceptos/blob/main/3_Plantillas/3_1_Requerimiento_atomico.md) especificar la versión
inicial de los requerimientos funcionales y no funcionales de esos casos de uso
del producto.
Pueden usar [historias de usuario](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Historia_de_usuario.md) para
especificar los requerimientos.
Estos requerimientos deben ser los más [arquitectónicamente
significativos](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Requerimiento_arquitectonicamente_significativo.md).
* Actualizar el [plan de pruebas](https://github.com/ucudal/ANDIS_Conceptos/blob/main/3_Plantillas/3_8_Plan_de_pruebas.md) y
agregar los [casos de
prueba](https://github.com/ucudal/ANDIS_Conceptos/blob/main/3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md) que demuestren
que el código entregado satisface los requerimientos atómicos que hayan
elegido para la prueba de concepto.
* Definir la arquitectura detallada que incluya por lo menos la [partición de
primer
nivel](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Componente.md#partición-de-la-arquitectura-en-componentes)
—partición técnica o partición por dominio— y refleje 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](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Epica.md) 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. Recuerden utilizar la [plantilla de requerimiento
atómico](https://github.com/ucudal/ANDIS_Conceptos/blob/main/3_Plantillas/3_1_Requerimiento_atomico.md).
* **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 terceros puedan ejecutar la solución en un ambiente de desarrollo.
Incluyan también el o los *pipelines* de CI/CD para probar, generar, integrar
y desplegar automáticamente el código.
* **Aseguramiento de la calidad**. Los [casos de
prueba](https://github.com/ucudal/ANDIS_Conceptos/blob/main/3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md) que demuestren
que el código entregado satisface los requerimientos que hayan elegido para la
prueba de concepto 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 etapa[^3]:
**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.
[^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.
### Primer *release*
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](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Solucion_consumible.md), en el primer *release* sí o
sí deben 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 entregan 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](https://github.com/features/actions), [Azure
Pipelines](https://azure.microsoft.com/es-es/products/devops/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
componentes](https://github.com/ucudal/ANDIS_Conceptos/blob/main/2_Tecnicas_y_herramientas/2_03_.Modelos_de_estructura/2_03_03_Diagramas_de_componentes_UML.md)
y [diagramas de
despliegue](https://github.com/ucudal/ANDIS_Conceptos/blob/main/2_Tecnicas_y_herramientas/2_03_.Modelos_de_estructura/2_03_04_Diagramas_de_despliegue_UML.md)
completos. Los [diagramas de
clases](https://github.com/ucudal/ANDIS_Conceptos/blob/main/2_Tecnicas_y_herramientas/2_03_.Modelos_de_estructura/2_03_01_Diagramas_de_clases_UML.md)
al menos con las clases del dominio. En caso de que corresponda, otros
[diagramas de
actividades](https://github.com/ucudal/ANDIS_Conceptos/blob/main/2_Tecnicas_y_herramientas/2_04_.Modelos_de_comportamiento/2_04_01_Diagramas_de_actividades_UML.md)
o
[secuencia](https://github.com/ucudal/ANDIS_Conceptos/blob/main/2_Tecnicas_y_herramientas/2_04_.Modelos_de_comportamiento/2_04_03_Diagramas_de_secuencia_UML.md).
* **Desarrollo**. El código funcionando que implementa requerimientos que hayan
decidido incluir en este etapa. Nuevamente incluyan instrucciones para que
terceros pueda ejecutar la solución en un ambiente diferente al del equipo del
proyecto.
* **Aseguramiento de la calidad**. 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 que la arquitectura satisface los
requerimientos no-funcionales.
* **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.
### Segundo *release*
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.
<!-- @diego es del MVP entregado en la etapa anterior? -->
* 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.
<!-- @diego acá se habla de funcionalidades, pero antes mencionamos épicas y
requerimientos; hay que ver con cuál nos quedamos. -->
Aunque no es obligatorio, recomendamos definir la interfaz de usuario con
herramientas de creación de prototipos como [Figma](https://www.figma.com),
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.
<!-- @fmachadopiriz poner que el criterio de ajuste es opcional antes. -->
* Completar la sección de calidad del documento entregable.
<!-- @fmachadopiriz ver qué de calidad se agrega antes si en este etapa es
sólo completar -->
* 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.
<!-- @diego cuáles serían las métricas que deben recolectar -->
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 componentes y de despliegue
actualizados. Los diagramas de clases con todas las clases —al menos las de
dominio— 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 que terceros
puedan ejecutar la solución en ambiente diferente al del equipo del proyecto.
* **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.
### *Delivery* completo
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 componentes y 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.
Otras pruebas que aseguren que la solución entregada cumple con los
requerimientos.
* **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.
Una retrospectiva reflexiva del proyecto como conclusión final.
## Entregas del proyecto final de grado
### Propuesta de proyecto
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](/1_Entregable_proyecto/1_1_1_Impulsores_del_proyecto.md#propósito-del-proyecto)
* [Interesados](/1_Entregable_proyecto/1_1_1_Impulsores_del_proyecto.md#los-interesados-o-stakeholders)
preliminares y borrador de sus necesidades clave. En particular identificar
quién de los
[interesados](https://github.com/ucudal/ANDIS_Conceptos/blob/main/4_Conceptos/4_Interesado.md)
actuará como encargado del proyecto de la contraparte y quién hace las veces
de patrocinador.
* El producto de la [etapa de anteproyecto](#anteproyecto) descrita antes.
### Primera entrega
* [Carta de
confidencialidad](https://github.com/ucudal/ANDIS_Conceptos/blob/main/3_Plantillas/3_6_Carta_confidencialidad_simple.md) o
[Compromiso de
confidencialidad](https://github.com/ucudal/ANDIS_Conceptos/blob/main/3_Plantillas/3_7_Compromiso_confidencialidad.md) según
corresponda.
* Documento entregable, con el contenido indicado para las etapas
[descubrimiento e inicio](#descubrimiento-e-inicio), [prueba de
concepto](#prueba-de-concepto) y [primer *release*](#primer-release).
### Segunda entrega
* Documento entregable, con el contenido indicado para la etapa de [segundo
*release*](#segundo-release).
### Entrega final
* [Carta de aceptación](https://github.com/ucudal/ANDIS_Conceptos/blob/main/3_Plantillas/3_5_Carta_aceptacion_cliente.md)
* Documento entregable, con el contenido indicado para la etapa de [*delivery*
completo](#delivery-completo).
### Defensa
* Presentación oral de 15 minutos, evaluada según [rúbrica de la
defensa](../2_Rubricas/2_2_Rubrica_defensa.md)
