From bbbedb5c205ce6cb760f0056c32f16b6b18991e1 Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Mon, 20 May 2024 18:13:13 -0300 Subject: [PATCH 01/18] Adding management discipline... work in progress --- 1_Contenido/1_4__Gestion.md | 96 +++++++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) diff --git a/1_Contenido/1_4__Gestion.md b/1_Contenido/1_4__Gestion.md index 0bddb14..7172629 100644 --- a/1_Contenido/1_4__Gestion.md +++ b/1_Contenido/1_4__Gestion.md @@ -1,3 +1,99 @@ # 1 Contenido ## 1.4 Gestión + +Este documento describe aspectos de gestión de proyectos en general y de los +proyectos de finales de grado en particular. + +La metodología para los proyectos finales de grado ha evolucionado a partir de +2024 y combina algunos aspectos del marco metodológico que usábamos +anteriormente con otros de metodologías ágiles actuales. + +Está basado 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 +este enfoque 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](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*. + +![](https://www.pmi.org/-/media/pmi/microsites/disciplined-agile/graphics/lifecycledadhighleveldeliverysmall.png?rev=56bc06a5ce0042d489c72f9f4ae711d7&sc_lang=en) + +El proyecto final de grado tiene los siguientes hitos, donde en cada hito hay +una entrega formal en webasignatura: + +* Inicio + +* Prueba de concepto + +* Primer *release* + +* Segundo *release* + +* *Delivery* al cliente y tercer *release* + +A partir de 2024 toda la documentación se entrega en un solo archivo o +repositorio siguiendo la estructura detallada en la sección +[Contenido](/1_Contenido/1__Contenido.md) de este repositorio. + +A continuación detallamos la correspondencia entre los hitos del proyecto final +de grado y las fases de DAD. + + + + + + + + + + + + + + + + + + + + + + + + +
+ Hitos en el proyecto final de grado + + Fases en DAD +
+ Inicio + + Inicio +
+ Prueba de concepto + + Construcción +
+ Primer *release* +
+ Segundo *release* +
+ *Delivery* al cliente y tercer *release* + + Transición +
+ From bdb1de7befcd695294009d034c3e0698d19a136b Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Thu, 30 May 2024 17:31:37 -0300 Subject: [PATCH 02/18] Added test case template --- .../3_4_Casos_de_prueba_de_usuario_final.md | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md diff --git a/3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md b/3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md new file mode 100644 index 0000000..8bbf736 --- /dev/null +++ b/3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md @@ -0,0 +1,92 @@ +# 3 Plantillas + +## 3.4 Casos de prueba de usuario final + +Esta es la plantilla para documentar los casos de prueba de usuario final. El +producto a probar es la aplicación desplegada en un ambiente de prueba. Aunque +la redacción de la plantilla asume una prueba manual, esta plantilla puede ser +utilizada también para escribir el guión de una prueba automatizada. + +Los casos de prueba de usuario final están agrupados en esta plantilla por +módulos. En este contexto un módulo puede ser un [caso de uso del +producto](/4_Conceptos/4_Caso_de_uso_del_producto.md) o una +[épica](/4_Conceptos/4_Epica.md). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Módulo + + Nombre del módulo +
+ Estado inicial + + Describir en qué estado debe estar la aplicación antes de iniciar + este caso de prueba —por ejemplo, si hay que importar o cargar + ciertos datos; o navegar hacia cierta pantalla, página o ventana de + la aplicación—; y si es necesario o no volver a ese estado al final + de cada uno de los casos a continuación. +
+ Número + + Descripción + + Procedimiento + + Resultados esperados +
+ #1 + + Descripción del caso de prueba #1 + + Pasos que el usuario debe realizar durante la prueba del caso #1. + + Resultado esperado en cada uno de los pasos del caso #1. +
+ #2 + + Descripción del caso de prueba #2 + + Pasos que el usuario debe realizar durante la prueba del caso #2. + + Resultado esperado en cada uno de los pasos del caso #2. +
+ ... + + ... + + ... + + ... +
From e6f976fc1f8a53382a7852d4b6504662f6926689 Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Thu, 30 May 2024 17:32:31 -0300 Subject: [PATCH 03/18] Added placeholder for deployment diagrams --- .../2_2_1_Diagramas_de_despliegue_UML.md | 8 ++++++++ 2_Tecnicas_y_herramientas/2_2__Modelos_de_arquitectura.md | 5 +++++ 2 files changed, 13 insertions(+) create mode 100644 2_Tecnicas_y_herramientas/2_2_1_Diagramas_de_despliegue_UML.md create mode 100644 2_Tecnicas_y_herramientas/2_2__Modelos_de_arquitectura.md diff --git a/2_Tecnicas_y_herramientas/2_2_1_Diagramas_de_despliegue_UML.md b/2_Tecnicas_y_herramientas/2_2_1_Diagramas_de_despliegue_UML.md new file mode 100644 index 0000000..3e02c10 --- /dev/null +++ b/2_Tecnicas_y_herramientas/2_2_1_Diagramas_de_despliegue_UML.md @@ -0,0 +1,8 @@ +# 2 Técnicas y herramientas + +## 2.2 Modelos de arquitectura + +### 2.2.1 Diagramas de despliegue UML + +TODO: Completa esta página de diagramas de despliegue en forma análoga a los +demás diagramas \ No newline at end of file diff --git a/2_Tecnicas_y_herramientas/2_2__Modelos_de_arquitectura.md b/2_Tecnicas_y_herramientas/2_2__Modelos_de_arquitectura.md new file mode 100644 index 0000000..6280bfc --- /dev/null +++ b/2_Tecnicas_y_herramientas/2_2__Modelos_de_arquitectura.md @@ -0,0 +1,5 @@ +# 2 Técnicas y herramientas + +## 2.2 Modelos de arquitectura + +### 2.2.1 [Diagramas de despliegue](./2_2_1_Diagramas_de_despliegue_UML.md) From e0dc0c6670e7b71c785035623c3ec2447dcd66f3 Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Thu, 30 May 2024 17:32:55 -0300 Subject: [PATCH 04/18] Added epic definition --- 4_Conceptos/4_Epica.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 4_Conceptos/4_Epica.md diff --git a/4_Conceptos/4_Epica.md b/4_Conceptos/4_Epica.md new file mode 100644 index 0000000..dcb5f46 --- /dev/null +++ b/4_Conceptos/4_Epica.md @@ -0,0 +1,19 @@ +# Conceptos + +## Épica o *epic* + +Cuando una [historia de usuario](./4_Historia_de_usuario.md) es muy grande[^1] se +suele llamar épica; las épicas se pueden dividir en dos o más historias de +usuario más pequeñas[^2]. + +Las épicas tienen el mismo formato que las historias de usuario. + +Al armar el [EDT](./4_EDT.md) o [*WBS*](./4_WBS.md) de tu plan de proyecto, +puedes usar épicas para agrupar funcionalidad de historias de usuario que +implementarás para un *release*. + +[^1]: Ya que una historia de usuario tiene una estimación de 1 a 3 semanas en el + "tiempo de desarrollo ideal", una historia de usuario "muy grande" tiene 4 + semanas o más. +[^2]: Cohn, M. (2004). User Stories Applied: For Agile Software Development. +Addison-Wesley Professional. From 05ef71aaef51f67a534edf727a051914a9fd3b50 Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Thu, 30 May 2024 17:35:22 -0300 Subject: [PATCH 05/18] Added management discipline first draft --- 1_Contenido/1_4__Gestion.md | 598 +++++++++++++++++- .../2_2_Modelos_de_arquitectura.md | 3 - 3_Plantillas/3_1_Requerimiento_atomico.md | 1 + 4_Conceptos/4_Historia_de_usuario.md | 3 +- 4_Conceptos/4_WBS.md | 2 +- diagrams/DAD_Lifecycle.drawio | 59 ++ diagrams/DAD_Lifecycle.svg | 1 + 7 files changed, 643 insertions(+), 24 deletions(-) delete mode 100644 2_Tecnicas_y_herramientas/2_2_Modelos_de_arquitectura.md create mode 100644 diagrams/DAD_Lifecycle.drawio create mode 100644 diagrams/DAD_Lifecycle.svg diff --git a/1_Contenido/1_4__Gestion.md b/1_Contenido/1_4__Gestion.md index 7172629..f44de14 100644 --- a/1_Contenido/1_4__Gestion.md +++ b/1_Contenido/1_4__Gestion.md @@ -2,22 +2,30 @@ ## 1.4 Gestión -Este documento describe aspectos de gestión de proyectos en general y de los -proyectos de finales de grado en particular. +Este documento describe aspectos de gestión de los proyectos de finales de grado +en particular. -La metodología para los proyectos finales de grado ha evolucionado a partir de -2024 y combina algunos aspectos del marco metodológico que usábamos -anteriormente con otros de metodologías ágiles actuales. +> [!NOTE] +> A diferencia de otras páginas en este repositorio, ésta está dirigida a los +> equipos que llevan adelante el proyecto final de grado —y no a un lector +> individual— por lo que notarán un cambio en el estilo de redacción —en otras +> páginas hubiéramos dicho "notarás"— :wink:. -Está basado en el enfoque [Disciplined Agile® +La metodología para los proyectos finales de grado 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 -este enfoque 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, +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 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: @@ -30,10 +38,17 @@ largo del tiempo: Cada una de estas fases puede tener una o más iteraciones o *sprints*. -![](https://www.pmi.org/-/media/pmi/microsites/disciplined-agile/graphics/lifecycledadhighleveldeliverysmall.png?rev=56bc06a5ce0042d489c72f9f4ae711d7&sc_lang=en) +![El ciclo de vida DAD](/diagrams/DAD_Lifecycle.svg) + +*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).* -El proyecto final de grado tiene los siguientes hitos, donde en cada hito hay -una entrega formal en webasignatura: +> [!TIP] +> Puedes ver las actividades en cada una de las fases de DAD en el [DA +> Browser](https://dabrowser.pmi.org). + +El proyecto final de grado tiene 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): * Inicio @@ -45,17 +60,51 @@ una entrega formal en webasignatura: * *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 los surgen las actividades y los productos +que se generan a lo largo del proyecto final de grado, como se detalla más +adelante. + A partir de 2024 toda la documentación se entrega en un solo archivo o repositorio siguiendo la estructura detallada en la sección [Contenido](/1_Contenido/1__Contenido.md) de este repositorio. -A continuación detallamos la correspondencia entre los hitos del proyecto final -de grado y las fases de DAD. +## 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. + + + + + + + - + + + + + + + +
- Hitos en el proyecto final de grado + Etapas en PFG + + Entregas en PFG Fases en DAD @@ -63,33 +112,61 @@ de grado y las fases de DAD.
+ Anteproyecto + + Propuesta de proyecto + Inicio
Inicio + Primera entrega +
Prueba de concepto + Construcción
- Primer *release* + Primer release
- Segundo *release* + Segundo release + + Segunda entrega
- *Delivery* al cliente y tercer *release* + Delivery al cliente y tercer release + + Entrega final +
+ Defensa +
+ No aplicable Transición @@ -97,3 +174,486 @@ de grado y las fases de DAD.
+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 inicio +del proyecto. El resto de las etapas del proyecto corresponden a la fase de +construcción en DAD. La fase de transición en DAD, cuya actividad principal es +el despliegue en producción, no aplica al proyecto final de grado. + +## Etapas del proyecto final de grado + +### Anteproyecto + +La etapa de anteproyecto es un tanto peculiar porque ocurre antes del inicio +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; puedes 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). + +Los productos esperados de esta etapa para cada dimensión son los siguientes: + +* **Requerimientos**. Los [eventos de negocio](/4_Conceptos/4_Evento_de_negocio.md) + más significativos. Incluyan para cada evento de negocio al menos su + descripción, sus datos, y si es de entrada o de salida. + + Los [caso de uso del negocio](/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 de 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](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 X y X +semanas. + +Los objetivos en esta etapa son: + +* Terminar de familiarizarte con el dominio del problema; tuviste tu primer + acercamiento cuando formulaste la propuesta, ahora deberás completar tu + entendimiento del dominio del problema. + +* Completar los eventos del negocio y los casos de uso del negocio; la mayoría + ya los identificaste para la propuesta durante el anteproyecto. + +* Armar un [EDT](/4_Conceptos/4_EDT.md) —o [*WBS*](/4_Conceptos/4_WBS.md)— + incluyendo el [MVP] y un listado de épicas para el alcance todo el proyecto; + este será el plan del proyecto. + + TODO: definir el MVP + +* Compartir con el cliente el plan del proyecto y validar expectativas sobre el + alcance del proyecto y las soluciones arquitectónicas que incluiste + oportunamente en la propuesta de proyecto —si no lo hubieras hecho todavía—. + +* Comenzar a escribir el documento entregable; puedes 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*, puedes 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, + te 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. + + 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]. + +### Prueba de concepto + +La segunda etapa del proyecto es la prueba de concepto. Dura entre x y x +semanas. + +Los objetivos de esta etapa son: + +* Relevar y especificar los [casos de uso del + producto](/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](/3_Plantillas/3_1_Requerimiento_atomico.md) especificar la versión + inicial de los requisitos funcionales y no funcionales de los casos de uso del + producto. + + Pueden usar [historias de usuario](/4_Conceptos/4_Historia_de_usuario.md) para + especificar los requerimientos. + +* Definir la arquitectura detallada y las tecnologías que vas 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](/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 del negocio + más significativos identificados en la etapa anterior. Incluyan en cada caso + de uso 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 completo. + + 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**. Pruebas de unidad para el código entregado. + +* **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. + +### Primer *release* + +La tercera etapa del proyecto es el primer *release*. Dura entre X y X semanas. + +Más allá de que en cada iteración produzcas 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 vengas 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 + despliegue](/2_Tecnicas_y_herramientas/2_2_1_Diagramas_de_despliegue_UML.md) + completos. Los [diagramas de + clases](/2_Tecnicas_y_herramientas/2_3_1_Diagramas_de_clases_UML.md) al menos + con las clases del dominio. En caso de que corresponda, otros [diagramas de + actividades](/2_Tecnicas_y_herramientas/2_4_1_Diagramas_de_actividades_UML.md) + o [secuencia](/2_Tecnicas_y_herramientas/2_4_3_Diagramas_de_secuencia_UML.md). + +* **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 de usuario final 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. + +### Segundo *release* + +La cuarta etapa del proyecto es el segundo *release*. Dura entre X y X 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](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. + + +* 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. + +### *Delivery* al cliente y tercer *release* + +Esta es la quinta y última etapa del proyecto. Dura entre X y X 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. + +## 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 [posicionamiento del + proyecto](/1_Contenido/1_1__Requisitos.md#posicionamiento-del-proyecto). + +* [Interesados](/1_Contenido/1_1__Requisitos.md#interesados-stakeholders) + preliminares. En particular identificar quién de los interesados actuará como + encargado del proyecto de la contraparte y quién hace las veces de + patrocinador. + +* Borrador de las [necesidades clave](/1_Contenido/1_1__Requisitos.md#identificación-de-necesidades-clave). + +* El producto de la [etapa de anteproyecto](#anteproyecto) descrita antes. + +### Primera entrega + +* Carta de confidencialidad + +* + +### Segunda entrega + +* + +### Entrega final + +* Carta de aceptación + +* + +[^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]: Ten en cuenta la seguridad y privacidad de la información que almacenes + en estos repositorios; si tienes un acuerdo de confidencialidad con el + cliente, deberías usar las herramientas recomendadas. También deberás + considerar que otras herramientas pueden tener costos asociados o limitar la + cantidad de usuarios o de archivos en las versiones gratuitas. + +[^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. diff --git a/2_Tecnicas_y_herramientas/2_2_Modelos_de_arquitectura.md b/2_Tecnicas_y_herramientas/2_2_Modelos_de_arquitectura.md deleted file mode 100644 index 3708d11..0000000 --- a/2_Tecnicas_y_herramientas/2_2_Modelos_de_arquitectura.md +++ /dev/null @@ -1,3 +0,0 @@ -# 2 Técnicas y herramientas - -## 2.2 Modelos de arquitectura diff --git a/3_Plantillas/3_1_Requerimiento_atomico.md b/3_Plantillas/3_1_Requerimiento_atomico.md index c0fedda..af390b0 100644 --- a/3_Plantillas/3_1_Requerimiento_atomico.md +++ b/3_Plantillas/3_1_Requerimiento_atomico.md @@ -57,6 +57,7 @@ y el texto a completar en el color normal. Tomado de [^1]. Criterio de ajuste + Una medida del requerimiento de forma tal que sea posible probar que diff --git a/4_Conceptos/4_Historia_de_usuario.md b/4_Conceptos/4_Historia_de_usuario.md index db45b98..b784d9c 100644 --- a/4_Conceptos/4_Historia_de_usuario.md +++ b/4_Conceptos/4_Historia_de_usuario.md @@ -47,7 +47,8 @@ Algunos sugieren que las historias de usuario tengan cierto formato[^3]: > quiero [característica o funcionalidad] > de modo que [razón] -*Persona* —ver [definición](https://www.merriam-webster.com/dictionary/persona)— representa el rol o el usuario. +*Persona* —ver [definición](https://www.merriam-webster.com/dictionary/persona)— +representa el rol o el usuario. > [!TIP] > Contesta las siguientes preguntas sobre la *persona*: diff --git a/4_Conceptos/4_WBS.md b/4_Conceptos/4_WBS.md index cf4bd08..85623e3 100644 --- a/4_Conceptos/4_WBS.md +++ b/4_Conceptos/4_WBS.md @@ -2,5 +2,5 @@ ## WBS o work breakdown structure -Ver [EDT](/4_Conceptos/4_EDT.md) +Ver [EDT](/4_Conceptos/4_EDT.md). diff --git a/diagrams/DAD_Lifecycle.drawio b/diagrams/DAD_Lifecycle.drawio new file mode 100644 index 0000000..2ed618d --- /dev/null +++ b/diagrams/DAD_Lifecycle.drawio @@ -0,0 +1,59 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/diagrams/DAD_Lifecycle.svg b/diagrams/DAD_Lifecycle.svg new file mode 100644 index 0000000..2990dfa --- /dev/null +++ b/diagrams/DAD_Lifecycle.svg @@ -0,0 +1 @@ +
Construcción
Construcción
Inicio o inception
Inicio o inception
Transición
Transición
Imaginar y planificar
Imaginar y planificar
Construir de forma incremental una solución consumible
Construir de forma incremental una solución consumible
Liberar la solución
Liberar la solución
Próxima liberación
Próxima liberaciónText is not SVG - cannot display \ No newline at end of file From e8737fc6c7bdf0dfbbc913bae0fe47111692026f Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Fri, 7 Jun 2024 17:43:55 -0300 Subject: [PATCH 06/18] Added proposal rubric --- 1_Contenido/1_4_1_Rubrica_propuesta.md | 170 +++++++++++++++++++++++++ 1_Contenido/1_4__Gestion.md | 104 ++++++++------- 2 files changed, 225 insertions(+), 49 deletions(-) create mode 100644 1_Contenido/1_4_1_Rubrica_propuesta.md diff --git a/1_Contenido/1_4_1_Rubrica_propuesta.md b/1_Contenido/1_4_1_Rubrica_propuesta.md new file mode 100644 index 0000000..9a0c208 --- /dev/null +++ b/1_Contenido/1_4_1_Rubrica_propuesta.md @@ -0,0 +1,170 @@ +# 1 Contenido + +## 1.4 Gestión + +## 1.4.1 Rúbrica propuesta + +Esta rúbrica es utilizada por el tribunal para evaluar las propuestas de +proyecto final de grado. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Ítem + + Rechazada + + Aceptable con modificaciones + + Aceptable +
+ Viabilidad del proyecto propuesto + + No es viable realizar el proyecto propuesto en el tiempo disponible; el + proyecto es demasiado grande o demasiado pequeño para un proyecto final de + grado. + + Podría ser viable con ciertas modificaciones. + El tribunal debe indicar qué modificaciones debería introducir el equipo + para que la propuesta sea aceptable. + + Es viable realizar el proyecto propuesto en el tiempo disponible. +
+ Aplicación en el proyecto propuesto de competencias adquiridas en la + carrera + + No es posible comprobar que en el proyecto propuesto los estudiantes + demostrarán un conjunto significativo de competencias adquiridas en su + carrera; el proyecto es trivial. + + Podría ser posible comprobar que en el proyecto propuesto los estudiantes + demostrarán un conjunto significativo de competencias adquiridas en su + carrera con ciertas modificaciones. El + tribunal debe indicar qué modificaciones debería introducir el equipo para + que la propuesta sea aceptable. + + A través del proyecto planteado es posible comprobar que los estudiantes + demostrarán un conjunto significativo de las competencias de su carrera. +
+ Capacidades de los estudiantes + + Los integrantes del equipo no indican sus capacidades dentro del proyecto + o las capacidades indicadas no son suficientes. + + Los integrantes del equipo deberán indicar sus capacidades dentro del + proyecto. +

+ o +

+ Podría ser posible modificar la propuesta para que las + capacidades indicadas por el equipo sean suficientes. + El tribunal debe indicar qué modificaciones + debería introducir el equipo para que la propuesta sea aceptable. + 		+ Los integrantes del equipo indican sus capacidades dentro del proyecto y + las capacidades indicadas son suficientes. +
+ Arquitectura preliminar y tecnologías previstas + + No se indica de forma clara la arquitectura preliminar o las tecnologías + previstas, o la arquitectura preliminar y tecnologías previstas no son + adecuadas para el proyecto propuesto. + + La arquitectura preliminar y las tecnologías previstas podrían ser + adecuadas con ciertas modificaciones. El + tribunal debe indicar qué modificaciones debería introducir el equipo para + que la propuesta sea aceptable. + + La propuesta de proyecto indica en forma clara la arquitectura y las + tecnologías previstas. +
+ Conocimiento del problema y de la solución + + El equipo no tiene un real conocimiento del problema del proyecto ni de + las funcionalidades que deberá tener la solución. + + El equipo podría mostrar que tiene un real conocimiento del problema del + proyecto y de las funcionalidades que deberá tener la solución con ciertas + modificaciones. El tribunal debe indicar qué + modificaciones debería introducir el equipo para que la propuesta sea + aceptable. + + El equipo tiene un real conocimiento del problema del proyecto y de las + funcionalidades que deberá tener la solución. +
+ Propósito del proyecto y partes interesadas + + El equipo no ha identificado el propósito del proyecto o las partes + interesadas de forma adecuada. + + El equipo debe identificar mejor el propósito del proyecto —el negocio y + otros antecedentes, objetivos del proyecto— y las partes interesadas + —cliente, usuarios—. + + El equipo ha identificado adecuadamente el propósito del proyecto —el + negocio y otros antecedentes, objetivos del proyecto— y las partes + interesadas —cliente, usuarios—. +
+ Conocimiento del personal adecuado del cliente + + El equipo no demuestra conocer la empresa o las contrapartes involucradas + no son las adecuadas. + + El equipo debe conocer mejor la empresa e identificar una contraparte + adecuada. + + El equipo demuestra conocer la empresa y las contrapartes involucradas son + las adecuadas. +
diff --git a/1_Contenido/1_4__Gestion.md b/1_Contenido/1_4__Gestion.md index f44de14..a9d21f0 100644 --- a/1_Contenido/1_4__Gestion.md +++ b/1_Contenido/1_4__Gestion.md @@ -5,9 +5,8 @@ Este documento describe aspectos de gestión de los proyectos de finales de grado en particular. -> [!NOTE] -> A diferencia de otras páginas en este repositorio, ésta está dirigida a los -> equipos que llevan adelante el proyecto final de grado —y no a un lector +> [!NOTE] A diferencia de otras páginas en este repositorio, ésta está dirigida +> a los equipos que llevan adelante el proyecto final de grado —y no a un lector > individual— por lo que notarán un cambio en el estilo de redacción —en otras > páginas hubiéramos dicho "notarás"— :wink:. @@ -43,12 +42,12 @@ 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](https://www.pmi.org/disciplined-agile/lifecycle).* -> [!TIP] -> Puedes ver las actividades en cada una de las fases de DAD en el [DA +> [!TIP] Puedes ver las actividades en cada una de las fases de DAD en el [DA > Browser](https://dabrowser.pmi.org). El proyecto final de grado tiene 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): +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): * Inicio @@ -60,9 +59,9 @@ tienen una entrega formal en webasignatura, según se indica [más adelante](#co * *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. +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 @@ -76,9 +75,9 @@ dimensión que en otras. * Gestión y proceso -De la combinación entre las etapas y los surgen las actividades y los productos -que se generan a lo largo del proyecto final de grado, como se detalla más -adelante. +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 partir de 2024 toda la documentación se entrega en un solo archivo o repositorio siguiendo la estructura detallada en la sección @@ -217,9 +216,10 @@ carrera](https://webasignatura.ucu.edu.uy/course/view.php?id=3751). Los productos esperados de esta etapa para cada dimensión son los siguientes: -* **Requerimientos**. Los [eventos de negocio](/4_Conceptos/4_Evento_de_negocio.md) - más significativos. Incluyan para cada evento de negocio al menos su - descripción, sus datos, y si es de entrada o de salida. +* **Requerimientos**. Los [eventos de + negocio](/4_Conceptos/4_Evento_de_negocio.md) más significativos. Incluyan + para cada evento de negocio al menos su descripción, sus datos, y si es de + entrada o de salida. Los [caso de uso del negocio](/4_Conceptos/4_Caso_de_uso_del_negocio.md) para cada evento del negocio identificado en el punto anterior. Del caso de uso del @@ -236,12 +236,14 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: * **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. +* **Aseguramiento de la calidad**. Pueden usar la [rúbrica de propuestas de + proyecto](/1_Contenido/1_4_1_Rubrica_propuesta.md) 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í. +* **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) @@ -278,8 +280,8 @@ Los objetivos en esta etapa son: 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. +* **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 @@ -294,8 +296,8 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: 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 +* **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*, puedes 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 @@ -304,10 +306,9 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: te 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. + > [!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. @@ -321,18 +322,18 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: 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**. 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 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 @@ -427,8 +428,8 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: La tercera etapa del proyecto es el primer *release*. Dura entre X y X semanas. -Más allá de que en cada iteración produzcas una [solución consumible](), en el primer -*release* sí o sí deberías tener una solución similar a la final, aunque +Más allá de que en cada iteración produzcas 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: @@ -472,9 +473,9 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: actividades](/2_Tecnicas_y_herramientas/2_4_1_Diagramas_de_actividades_UML.md) o [secuencia](/2_Tecnicas_y_herramientas/2_4_3_Diagramas_de_secuencia_UML.md). -* **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. +* **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. @@ -486,7 +487,8 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: 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. +* **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. @@ -497,7 +499,8 @@ La cuarta etapa del proyecto es el segundo *release*. Dura entre X y X semanas. Los objetivos de esta etapa son: -* Conseguir retroalimentación del cliente respecto del MVP. +* 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* @@ -554,7 +557,8 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: 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. +* **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. @@ -624,7 +628,8 @@ Contenido de la propuesta: encargado del proyecto de la contraparte y quién hace las veces de patrocinador. -* Borrador de las [necesidades clave](/1_Contenido/1_1__Requisitos.md#identificación-de-necesidades-clave). +* Borrador de las [necesidades + clave](/1_Contenido/1_1__Requisitos.md#identificación-de-necesidades-clave). * El producto de la [etapa de anteproyecto](#anteproyecto) descrita antes. @@ -645,14 +650,15 @@ Contenido de la propuesta: * [^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) + [Health Endpoint + Monitoring](https://learn.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring) por ejemplo. -[^2]: Ten en cuenta la seguridad y privacidad de la información que almacenes - en estos repositorios; si tienes un acuerdo de confidencialidad con el - cliente, deberías usar las herramientas recomendadas. También deberás - considerar que otras herramientas pueden tener costos asociados o limitar la - cantidad de usuarios o de archivos en las versiones gratuitas. +[^2]: Ten en cuenta la seguridad y privacidad de la información que almacenes en + estos repositorios; si tienes un acuerdo de confidencialidad con el cliente, + deberías usar las herramientas recomendadas. También deberás considerar que + otras herramientas pueden tener costos asociados o limitar la cantidad de + usuarios o de archivos en las versiones gratuitas. [^3]: Estos reportes pueden ser generados automáticamente con la herramienta Azure DevOps recomendada, no tienen porqué hacerlos a mano si la usan para From 5d70a13d8ab2e0f347ea6c0a002572edd58ed6a7 Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Fri, 7 Jun 2024 20:34:57 -0300 Subject: [PATCH 07/18] Templates added --- 3_Plantillas/3_5_Aceptacion_cliente.md | 33 ++++++ .../3_6_Carta_confidencialidad_simple.md | 34 ++++++ .../3_7_Compromiso_confidencialidad.md | 112 ++++++++++++++++++ 3 files changed, 179 insertions(+) create mode 100644 3_Plantillas/3_5_Aceptacion_cliente.md create mode 100644 3_Plantillas/3_6_Carta_confidencialidad_simple.md create mode 100644 3_Plantillas/3_7_Compromiso_confidencialidad.md diff --git a/3_Plantillas/3_5_Aceptacion_cliente.md b/3_Plantillas/3_5_Aceptacion_cliente.md new file mode 100644 index 0000000..e836551 --- /dev/null +++ b/3_Plantillas/3_5_Aceptacion_cliente.md @@ -0,0 +1,33 @@ +# 3 Plantillas + +## 3.x Carta de aceptación del cliente + +Esta es la plantilla para la carta en la que el cliente acepta los entregables +del proyecto final de grado. + +> [!NOTE] +> Reemplazar el texto entre `≪` y `≫` con la información correspondiente. + +`≪lugar≫`, `≪fecha≫` + +Coordinación de Proyectos Finales de Grado de Informática +
+Facultad de Ingeniería y Tecnologías +
+Universidad Católica del Uruguay + +Por la presente, se deja constancia que el proyecto `≪nombre del proyecto≫`, +desarrollado por los estudiantes `≪nombre de todos los estudiantes en orden +alfabético por su apellido≫` dentro del marco de la asignatura Proyecto Final de +Grado de la Facultad de Ingeniería en Informática de la Universidad Católica del +Uruguay, fue completado de acuerdo con lo convenido entre las partes. + +Por `≪nombre de la organización≫`: + +`≪firma≫` +
+Firma + +`≪aclaración≫` +
+Aclaración diff --git a/3_Plantillas/3_6_Carta_confidencialidad_simple.md b/3_Plantillas/3_6_Carta_confidencialidad_simple.md new file mode 100644 index 0000000..9a6c171 --- /dev/null +++ b/3_Plantillas/3_6_Carta_confidencialidad_simple.md @@ -0,0 +1,34 @@ +# 3 Plantillas + +## 3.x Carta de confidencialidad + +Esta carta la firma cada uno de los estudiantes del equipo del proyecto y +entregan una copia en la empresa en la que están desarrollando el proyecto y +otra copia la envían al tutor del proyecto o al coordinador. + +A menos que la empresa, el tutor, o el coordinador indiquen lo contrario, usen +esta versión y no [esta](/3_Plantillas/3_7_Compromiso_confidencialidad.md). + +> [!NOTE] +> Reemplazar el texto entre `≪` y `≫` con la información correspondiente. + +`≪lugar≫`, `≪fecha≫` + +Quien suscribe, `≪nombre del estudiante≫`, titular de la cédula de identidad +`≪numero de cédula de identidad del estudiante≫`, alumno de Proyecto Final de +Grado de la Universidad Católica del Uruguay, por la presente declara estar +desarrollando un proyecto de Ingeniería Informática en la empresa `≪nombre de la +empresa≫`. + +El suscrito se obliga a mantener el carácter de confidencialidad de toda +información referente a dicha empresa o de su actividad, que haya tomado +conocimiento directa o indirectamente durante el desarrollo del presente +proyecto. + +`≪firma≫` +
+Firma + +`≪aclaración≫` +
+Aclaración diff --git a/3_Plantillas/3_7_Compromiso_confidencialidad.md b/3_Plantillas/3_7_Compromiso_confidencialidad.md new file mode 100644 index 0000000..5f3d7fd --- /dev/null +++ b/3_Plantillas/3_7_Compromiso_confidencialidad.md @@ -0,0 +1,112 @@ +# 3 Plantillas + +## 3.x Compromiso de confidencialidad + +Este es un documento de confidencialidad más completo que la [carta de/3_Plantillas/3_6_Carta_confidencialidad_simple.md +confidencialidad](/3_Plantillas/3_x_Carta_confidencialidad_simple.md) y lo firma +cada uno de los estudiantes del equipo del proyecto y entregan una copia en la +empresa en la que están desarrollando el proyecto y otra copia la envían al +tutor del proyecto o al coordinador. + +> [!NOTE] +> Reemplazar el texto entre `≪` y `≫` con la información correspondiente. + +, `≪fecha≫` + +**COMPROMISO DE CONFIDENCIALIDAD DE ESTUDIANTES EN PROYECTOS DE FINAL DE GRADO EN +UCU O EN TERCERAS ENTIDADES** + +`≪El o la≫` estudiante, `≪nombre del estudiante≫`, con C.I. o documento de +identidad `≪número de cédula de identidad del estudiante≫`, que cursa sus +estudios de grado universitario en la carrera de Ingeniería en Informática en la +Universidad Católica del Uruguay, se compromete a mantener absoluta +confidencialidad y reserva de la información, documentos y datos, especialmente +los datos personales (en adelante referida genéricamente como “información”), +que estén disponibles en cualquier formato (ya sea físico o digital) a los que +pueda acceder en el desarrollo de las actividades propias a su participación en +el PROYECTO `≪nombre del proyecto≫`, en adelante el “Proyecto”, en el marco del +Proyecto Final de Grado de la carrera de Ingeniería en Informática de la UCU. + +`≪El o la≫` estudiante estará obligado en oportunidad o con motivo de la +realización de las actividades que le competan en la ejecución del Proyecto a +guardar confidencialidad y reserva en relación con la información interna propia +de la UCU cualquiera sea su naturaleza, y guardar secreto profesional sobre sus +actividades, así como con relación a la información de cualquier naturaleza, +relativa a terceras personas físicas o jurídicas vinculadas a aquella, a la que +tenga acceso durante su participación en el Proyecto, así como luego de +finalizada ésta, quedando sujeto a las responsabilidades de cualquier naturaleza +que pudieran derivarse de su incumplimiento. + +`≪El o la≫` estudiante será responsable de todos los daños y perjuicios que se +deriven para la UCU o para los terceros vinculados a la misma, como consecuencia +del incumplimiento doloso o culposo de dicha obligación. Por consiguiente, `≪el +o la≫` estudiante no podrá hacer uso de información, datos o documentos que +conciernan a la institución o a cualquier persona física o jurídica que se +encuentre vinculada a la misma (usuarios, clientes, proveedores, contactos, o +cualquier otro), con una finalidad distinta o más allá de la requerida para la +realización de las actividades que le sean asignadas por la UCU en la ejecución +del Proyecto, ni divulgará, comunicará, transmitirá, ni cederá a terceros, por +cualquier medio o canal, en modo alguno, la información, datos y documentos a +los que pueda acceder. + +Asimismo, en cualquier caso se entenderá que tiene dicha condición toda +información que contenga datos de carácter personal, entendidos éstos como +cualquier información (numérica, alfabética, gráfica, fotográfica, acústica o de +cualquier otro tipo) concerniente o referida a personas físicas o jurídicas +determinadas o determinables, ya sean propios de la UCU, o relativos a cualquier +tercero vinculado a dicha institución, cualquiera sea la naturaleza de dicho +vínculo, y de la actividad que dio origen a su recolección. + +Los datos de carácter personal serán objeto de protección, reserva y tratamiento +confidencial por parte del estudiante en todo caso, especialmente aquellos +datos sensibles, entendiéndose por tales, los datos personales que revelen +origen racial y étnico, preferencias políticas, convicciones religiosas o +morales, afiliación sindical e informaciones referentes a la salud o a la vida +sexual de las personas, y todo otro considera tal, de conformidad con la +normativa nacional aplicable en la materia. + +Si `≪el o la≫` estudiante tuviere acceso o interviniere en cualquier fase del +tratamiento de datos personales contenidos en bases de datos de la UCU respecto +de las cuales esta sea responsable o encargada de tratamiento, deberá actuar con +reserva y confidencialidad sobre los mismos, guardando además estricto secreto +profesional, en un todo de acuerdo a lo previsto en el artículo 302 del Código +Penal, según la remisión efectuada por el artículo 11 de la Ley N° 18.331 sobre +Protección de Datos Personales. + +El cumplimiento por parte `≪del o de la≫` estudiante de las obligaciones que por +el presente asume en materia de finalidad en el acceso y utilización de la +información, datos y documentos referidos anteriormente, así como en cuanto a la +integridad, confidencialidad y reserva de los mismos y demás obligaciones de su +cargo, será responsabilidad exclusiva de `≪aquel o aquella≫` frente a la UCU o +frente a terceros. De incurrirse por el estudiante en tal incumplimiento, la +UCU queda facultada desde ya, a dar por rescindido el contrato de prestación de +servicios de enseñanza que la vincula con `≪el o la≫` estudiante, en forma +automática y de pleno derecho y sin necesidad de gestión extrajudicial o +judicial de clase alguna, operando en todo caso la mora automática. Lo anterior, +es sin perjuicios de las responsabilidades que le puedan caber al estudiante +derivadas de los daños y perjuicios causados, así como toda otra de cualquier +naturaleza. + +Sin perjuicio de lo previsto en este documento, se deja constancia en este acto, +que el estudiante participará en el proyecto `≪nombre del proyecto≫` en la +empresa `≪nombre de la empresa≫`, respecto de la cual rigen todos los términos y +condiciones incluidos en la presente. + +Por la firma del presente compromiso, `≪el o la≫` estudiante declara que conoce +y comprende plenamente el contenido y alcance de su obligación de +confidencialidad y reserva a que refiere el presente documento. Para constancia, +y en señal de aceptación, se firma el presente en la ciudad de `≪lugar≫` a los +`≪día en letras≫` (`≪día en números≫`) días del mes de `≪mes en letras≫` de +`≪año en números≫`. + +`≪firma≫` +
+Firma + +`≪aclaración≫` +
+Aclaración + +`≪número de documento de identidad≫` +
+Documento de identidad From 9f90109fd7b9f6c6b0d86c83c1da711a02f1a66e Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Fri, 7 Jun 2024 20:35:14 -0300 Subject: [PATCH 08/18] Management section in progress --- 1_Contenido/1_4__Gestion.md | 52 +++++++++++---------- 3_Plantillas/3_1_Requerimiento_atomico.md | 25 ++++++++-- 4_Conceptos/4_MVP.md | 56 ++++++++++++++++++++++- 3 files changed, 105 insertions(+), 28 deletions(-) diff --git a/1_Contenido/1_4__Gestion.md b/1_Contenido/1_4__Gestion.md index a9d21f0..84901e2 100644 --- a/1_Contenido/1_4__Gestion.md +++ b/1_Contenido/1_4__Gestion.md @@ -5,8 +5,9 @@ Este documento describe aspectos de gestión de los proyectos de finales de grado en particular. -> [!NOTE] A diferencia de otras páginas en este repositorio, ésta está dirigida -> a los equipos que llevan adelante el proyecto final de grado —y no a un lector +> [!NOTE] +> A diferencia de otras páginas en este repositorio, ésta está dirigida a los +> equipos que llevan adelante el proyecto final de grado —y no a un lector > individual— por lo que notarán un cambio en el estilo de redacción —en otras > páginas hubiéramos dicho "notarás"— :wink:. @@ -42,7 +43,8 @@ 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](https://www.pmi.org/disciplined-agile/lifecycle).* -> [!TIP] Puedes ver las actividades en cada una de las fases de DAD en el [DA +> [!TIP] +> Puedes ver las actividades en cada una de las fases de DAD en el [DA > Browser](https://dabrowser.pmi.org). El proyecto final de grado tiene las siguientes etapas, donde algunas de ellas @@ -258,18 +260,17 @@ semanas. Los objetivos en esta etapa son: -* Terminar de familiarizarte con el dominio del problema; tuviste tu primer - acercamiento cuando formulaste la propuesta, ahora deberás completar tu +* 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 identificaste para la propuesta durante el anteproyecto. + ya los identificaron para la propuesta durante el anteproyecto. * Armar un [EDT](/4_Conceptos/4_EDT.md) —o [*WBS*](/4_Conceptos/4_WBS.md)— - incluyendo el [MVP] y un listado de épicas para el alcance todo el proyecto; - este será el plan del proyecto. - - TODO: definir el MVP + incluyendo el [MVP](/4_Conceptos/4_MVP.md) y un listado de + [épicas](/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 incluiste @@ -306,9 +307,10 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: te 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. + > [!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. @@ -408,19 +410,19 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: 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 + ***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 + ***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 + ***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 + ***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. @@ -505,9 +507,8 @@ Los objetivos de esta etapa son: * 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](https://www.figma.com), @@ -518,7 +519,8 @@ Los objetivos de esta etapa son: * Completar la sección de calidad del documento entregable. - + * Actualizar las secciones de arquitectura y diseño si corresponde. @@ -635,7 +637,11 @@ Contenido de la propuesta: ### Primera entrega -* Carta de confidencialidad +* [Carta de + confidencialidad](/3_Plantillas/3_x_Carta_confidencialidad_simple.md) o + [Compromiso de + confidencialidad](/3_Plantillas/3_x_Compromiso_confidencialidad.md) según + corresponda. * @@ -645,7 +651,7 @@ Contenido de la propuesta: ### Entrega final -* Carta de aceptación +* [Carta de aceptación](/3_Plantillas/3_5_Aceptacion_cliente.md) * diff --git a/3_Plantillas/3_1_Requerimiento_atomico.md b/3_Plantillas/3_1_Requerimiento_atomico.md index af390b0..458c506 100644 --- a/3_Plantillas/3_1_Requerimiento_atomico.md +++ b/3_Plantillas/3_1_Requerimiento_atomico.md @@ -87,7 +87,9 @@ y el texto a completar en el color normal. Tomado de [^1]. Prioridad - Una calificación del valor de este requerimiento para los usuarios finales + Una calificación del valor de este requerimiento para los usuarios + finales. Ver debajo ↓ + @@ -135,8 +137,25 @@ y el texto a completar en el color normal. Tomado de [^1]. * Impulsor o *driver* del proyecto * Cuestiones o *issues* del proyecto ↩︎ -Lista de identificadores de eventos o casos de uso que necesitan -este requerimiento. ↩︎ +#Evento/Caso de uso: + +* Lista de identificadores de eventos o casos de uso que necesitan +este requerimiento.↩︎ + +Prioridad: + +* ***Must have* —imprescindibles—**: Requerimientos críticos que el proyecto + debe cumplir para ser considerado exitoso. Sin ellos el proyecto no cumplirá + su propósito. + +* ***Should have* —importantes—**: Requerimientos que son importantes pero no + críticos. Su ausencia no detendrá el proyecto, pero puede afectar la calidad o + eficiencia del resultado final. + +* ***Nice to have* —deseables—**: Estos son los requerimientos que sería + beneficioso tener, pero que no son esenciales. Mejoran la experiencia o la + funcionalidad, pero no afectan la viabilidad del proyecto. + ↩︎ [^1]: Robertson, S. & Robertson, J. (2012). Mastering the Requirements Process: Getting Requirements Right, 3rd Edition. Addison-Wesley Professional. diff --git a/4_Conceptos/4_MVP.md b/4_Conceptos/4_MVP.md index e66dee0..d7fb4ad 100644 --- a/4_Conceptos/4_MVP.md +++ b/4_Conceptos/4_MVP.md @@ -2,5 +2,57 @@ ## MVP o mínimo producto viable -TODO: Completar MVP con información de PMI -https://www.pmi.org/disciplined-agile/process/product-management/mvps-and-mbis \ No newline at end of file +El término MVP —*minimum viable product*— o mínimo producto viable fue +popularizado entre otros por Eric Ries[^1]. Un MVP es una versión de un nuevo +producto que permite a un equipo recopilar la máxima cantidad de aprendizaje +validado sobre los clientes con el menor esfuerzo. + +La definición de MVP se da en el contexto de una *start-up*. La actividad +fundamental de una *startup* es convertir ideas en productos, medir cómo responden +los clientes y luego aprender si pivotar o perseverar. A esto se le llama el +ciclo "construir-medir-aprender". + +El MVP es esa versión del producto que permite una vuelta completa del ciclo +construir-medir-aprender con una mínima cantidad de esfuerzo y la menor cantidad +de tiempo de desarrollo. El MVP carece de muchas características que pueden +resultar esenciales más adelante. Sin embargo, en cierto modo, crear un MVP +requiere trabajo extra: debemos poder medir su impacto. + +El MVP ayuda a los emprendedores a iniciar el proceso de aprendizaje lo más +rápido posible. Sin embargo, no es necesariamente el producto más pequeño +imaginable; es simplemente la forma más rápida de superar el ciclo de +retroalimentación construir-medir-aprender con el mínimo esfuerzo. A diferencia +del desarrollo de productos tradicional, que normalmente implica un largo y +reflexivo período de incubación y se esfuerza por alcanzar la perfección del +producto, el objetivo del MVP es comenzar el proceso de aprendizaje, no +terminarlo. A diferencia de un prototipo o una prueba de concepto, un MVP está +diseñado no solo para responder preguntas técnicas o de diseño de producto. Su +objetivo es probar hipótesis de negocio fundamentales. + +Los MVP varían en complejidad, desde pruebas de humo extremadamente simples +—poco más que un anuncio— hasta prototipos iniciales completos con problemas y +características faltantes. Decidir exactamente qué tan complejo debe ser un MVP +no se puede hacer mediante fórmulas. Requiere juicio. Afortunadamente, este +juicio no es difícil de desarrollar: la mayoría de los emprendedores y personas +de desarrollo de productos sobrestiman dramáticamente cuántas características +se necesitan en un MVP. En caso de duda, simplifica. + +Para el PMI un MVP es una inversión en aprendizaje, un experimento donde su +objetivo es explorar lo que quiere un cliente potencial. Para ejecutar este +experimento, creas una versión de un producto con el menor esfuerzo posible para +utilizarlo en el aprendizaje validado sobre los clientes potenciales. Los MVP +son experimentos para explorar una hipótesis sobre lo que realmente quieren los +clientes. No corresponden a la versión "real" de su producto final porque no +están al nivel de calidad o escala con que se produciría el producto final. +Dicho esto, los MVP pueden evolucionar hasta convertirse en un producto real, o +más exactamente en un MBI —*minimum business increment*— real, pero la mayoría +de las veces evolucionan hasta convertirse en algo más parecido a un prototipo +—lo cual está bien porque son una inversión en aprendizaje y nunca estuvieron +destinados a ser reales—. Por lo general, un equipo ejecuta el experimento con +un subconjunto de sus clientes potenciales para probar una nueva idea, recopilar +datos sobre ella y así descubrir que los clientes están realmente +interesados[^2]. + +[^1]: Ries, E. (2011). The Lean Startup. Crown Currency. + +[^2]: Project Management Institute. (2024). MVPs and MBIs. [Link](https://www.pmi.org/disciplined-agile/process/product-management/mvps-and-mbis). \ No newline at end of file From 2e65561192ddaa15351e4c3e20fa481a0adfdc2d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fernando=20Machado=20P=C3=ADriz?= Date: Tue, 11 Jun 2024 17:46:46 -0300 Subject: [PATCH 09/18] Update 1_Contenido/1_4__Gestion.md Co-authored-by: Paolo Mazza <47277080+PaoloMazza1204@users.noreply.github.com> --- 1_Contenido/1_4__Gestion.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/1_Contenido/1_4__Gestion.md b/1_Contenido/1_4__Gestion.md index 84901e2..79b39f5 100644 --- a/1_Contenido/1_4__Gestion.md +++ b/1_Contenido/1_4__Gestion.md @@ -638,9 +638,9 @@ Contenido de la propuesta: ### Primera entrega * [Carta de - confidencialidad](/3_Plantillas/3_x_Carta_confidencialidad_simple.md) o + confidencialidad](/3_Plantillas/3_6_Carta_confidencialidad_simple.md) o [Compromiso de - confidencialidad](/3_Plantillas/3_x_Compromiso_confidencialidad.md) según + confidencialidad](/3_Plantillas/3_7_Compromiso_confidencialidad.md) según corresponda. * From 36353b7ab1213dcb595633a47a620b71b2bb4b1e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fernando=20Machado=20P=C3=ADriz?= Date: Tue, 11 Jun 2024 17:46:56 -0300 Subject: [PATCH 10/18] Update 3_Plantillas/3_6_Carta_confidencialidad_simple.md Co-authored-by: Paolo Mazza <47277080+PaoloMazza1204@users.noreply.github.com> --- 3_Plantillas/3_6_Carta_confidencialidad_simple.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/3_Plantillas/3_6_Carta_confidencialidad_simple.md b/3_Plantillas/3_6_Carta_confidencialidad_simple.md index 9a6c171..0911d4d 100644 --- a/3_Plantillas/3_6_Carta_confidencialidad_simple.md +++ b/3_Plantillas/3_6_Carta_confidencialidad_simple.md @@ -1,6 +1,6 @@ # 3 Plantillas -## 3.x Carta de confidencialidad +## 3.6 Carta de confidencialidad Esta carta la firma cada uno de los estudiantes del equipo del proyecto y entregan una copia en la empresa en la que están desarrollando el proyecto y From 79f625538251f492528a20d5da230e7b2e0a37cf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fernando=20Machado=20P=C3=ADriz?= Date: Tue, 11 Jun 2024 17:47:09 -0300 Subject: [PATCH 11/18] Update 3_Plantillas/3_7_Compromiso_confidencialidad.md Co-authored-by: Paolo Mazza <47277080+PaoloMazza1204@users.noreply.github.com> --- 3_Plantillas/3_7_Compromiso_confidencialidad.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/3_Plantillas/3_7_Compromiso_confidencialidad.md b/3_Plantillas/3_7_Compromiso_confidencialidad.md index 5f3d7fd..61034ed 100644 --- a/3_Plantillas/3_7_Compromiso_confidencialidad.md +++ b/3_Plantillas/3_7_Compromiso_confidencialidad.md @@ -88,7 +88,7 @@ derivadas de los daños y perjuicios causados, así como toda otra de cualquier naturaleza. Sin perjuicio de lo previsto en este documento, se deja constancia en este acto, -que el estudiante participará en el proyecto `≪nombre del proyecto≫` en la +que `≪el o la≫` estudiante participará en el proyecto `≪nombre del proyecto≫` en la empresa `≪nombre de la empresa≫`, respecto de la cual rigen todos los términos y condiciones incluidos en la presente. From dfc2a43218b8ed75b33663d24e6a487898ec4646 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fernando=20Machado=20P=C3=ADriz?= Date: Tue, 11 Jun 2024 17:47:17 -0300 Subject: [PATCH 12/18] Update 3_Plantillas/3_5_Aceptacion_cliente.md Co-authored-by: Paolo Mazza <47277080+PaoloMazza1204@users.noreply.github.com> --- 3_Plantillas/3_5_Aceptacion_cliente.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/3_Plantillas/3_5_Aceptacion_cliente.md b/3_Plantillas/3_5_Aceptacion_cliente.md index e836551..39326b9 100644 --- a/3_Plantillas/3_5_Aceptacion_cliente.md +++ b/3_Plantillas/3_5_Aceptacion_cliente.md @@ -1,6 +1,6 @@ # 3 Plantillas -## 3.x Carta de aceptación del cliente +## 3.5 Carta de aceptación del cliente Esta es la plantilla para la carta en la que el cliente acepta los entregables del proyecto final de grado. From e1158031e9ed1304429af69e1df01b927f35412e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fernando=20Machado=20P=C3=ADriz?= Date: Tue, 11 Jun 2024 17:47:32 -0300 Subject: [PATCH 13/18] Update 4_Conceptos/4_MVP.md Co-authored-by: Paolo Mazza <47277080+PaoloMazza1204@users.noreply.github.com> --- 4_Conceptos/4_MVP.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/4_Conceptos/4_MVP.md b/4_Conceptos/4_MVP.md index d7fb4ad..5c9d45f 100644 --- a/4_Conceptos/4_MVP.md +++ b/4_Conceptos/4_MVP.md @@ -32,7 +32,7 @@ objetivo es probar hipótesis de negocio fundamentales. Los MVP varían en complejidad, desde pruebas de humo extremadamente simples —poco más que un anuncio— hasta prototipos iniciales completos con problemas y características faltantes. Decidir exactamente qué tan complejo debe ser un MVP -no se puede hacer mediante fórmulas. Requiere juicio. Afortunadamente, este +no se puede hacer mediante fórmulas; requiere juicio. Afortunadamente, este juicio no es difícil de desarrollar: la mayoría de los emprendedores y personas de desarrollo de productos sobrestiman dramáticamente cuántas características se necesitan en un MVP. En caso de duda, simplifica. From efdf8f8995e53893cc5affcbc3fcbefe588f2c4b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fernando=20Machado=20P=C3=ADriz?= Date: Tue, 11 Jun 2024 17:48:53 -0300 Subject: [PATCH 14/18] Apply suggestions from code review Co-authored-by: Paolo Mazza <47277080+PaoloMazza1204@users.noreply.github.com> --- 3_Plantillas/3_7_Compromiso_confidencialidad.md | 10 +++++----- 4_Conceptos/4_WBS.md | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/3_Plantillas/3_7_Compromiso_confidencialidad.md b/3_Plantillas/3_7_Compromiso_confidencialidad.md index 61034ed..cea582c 100644 --- a/3_Plantillas/3_7_Compromiso_confidencialidad.md +++ b/3_Plantillas/3_7_Compromiso_confidencialidad.md @@ -2,8 +2,8 @@ ## 3.x Compromiso de confidencialidad -Este es un documento de confidencialidad más completo que la [carta de/3_Plantillas/3_6_Carta_confidencialidad_simple.md -confidencialidad](/3_Plantillas/3_x_Carta_confidencialidad_simple.md) y lo firma +Este es un documento de confidencialidad más completo que la [carta de +confidencialidad simple](/3_Plantillas/3_6_Carta_confidencialidad_simple.md) y lo firma cada uno de los estudiantes del equipo del proyecto y entregan una copia en la empresa en la que están desarrollando el proyecto y otra copia la envían al tutor del proyecto o al coordinador. @@ -11,7 +11,7 @@ tutor del proyecto o al coordinador. > [!NOTE] > Reemplazar el texto entre `≪` y `≫` con la información correspondiente. -, `≪fecha≫` +`≪lugar≫`, `≪fecha≫` **COMPROMISO DE CONFIDENCIALIDAD DE ESTUDIANTES EN PROYECTOS DE FINAL DE GRADO EN UCU O EN TERCERAS ENTIDADES** @@ -58,7 +58,7 @@ tercero vinculado a dicha institución, cualquiera sea la naturaleza de dicho vínculo, y de la actividad que dio origen a su recolección. Los datos de carácter personal serán objeto de protección, reserva y tratamiento -confidencial por parte del estudiante en todo caso, especialmente aquellos +confidencial por parte `≪del o de la≫` estudiante en todo caso, especialmente aquellos datos sensibles, entendiéndose por tales, los datos personales que revelen origen racial y étnico, preferencias políticas, convicciones religiosas o morales, afiliación sindical e informaciones referentes a la salud o a la vida @@ -78,7 +78,7 @@ el presente asume en materia de finalidad en el acceso y utilización de la información, datos y documentos referidos anteriormente, así como en cuanto a la integridad, confidencialidad y reserva de los mismos y demás obligaciones de su cargo, será responsabilidad exclusiva de `≪aquel o aquella≫` frente a la UCU o -frente a terceros. De incurrirse por el estudiante en tal incumplimiento, la +frente a terceros. De incurrirse por `≪el o la≫` estudiante en tal incumplimiento, la UCU queda facultada desde ya, a dar por rescindido el contrato de prestación de servicios de enseñanza que la vincula con `≪el o la≫` estudiante, en forma automática y de pleno derecho y sin necesidad de gestión extrajudicial o diff --git a/4_Conceptos/4_WBS.md b/4_Conceptos/4_WBS.md index 85623e3..c410360 100644 --- a/4_Conceptos/4_WBS.md +++ b/4_Conceptos/4_WBS.md @@ -1,6 +1,6 @@ # Conceptos -## WBS o work breakdown structure +## WBS o *work breakdown structure* Ver [EDT](/4_Conceptos/4_EDT.md). From a9597de39799be2afc13a40f346d2546d4ee5909 Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Tue, 11 Jun 2024 17:49:52 -0300 Subject: [PATCH 15/18] Added consumable solution placeholder --- 4_Conceptos/4_Solucion_consumible.md | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 4_Conceptos/4_Solucion_consumible.md diff --git a/4_Conceptos/4_Solucion_consumible.md b/4_Conceptos/4_Solucion_consumible.md new file mode 100644 index 0000000..12bf112 --- /dev/null +++ b/4_Conceptos/4_Solucion_consumible.md @@ -0,0 +1,5 @@ +# 4 Conceptos + +## Solución consumible + +TODO: Tomar contenido de aquí: https://www.pmi.org/disciplined-agile/consumable-solutions \ No newline at end of file From 36ffe6a39e8d6289c4fa854b437af3020a89a2e1 Mon Sep 17 00:00:00 2001 From: Fernando Machado Date: Tue, 11 Jun 2024 17:50:30 -0300 Subject: [PATCH 16/18] Apply suggestions from code review --- 1_Contenido/1_4__Gestion.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/1_Contenido/1_4__Gestion.md b/1_Contenido/1_4__Gestion.md index 79b39f5..b4871ff 100644 --- a/1_Contenido/1_4__Gestion.md +++ b/1_Contenido/1_4__Gestion.md @@ -430,11 +430,12 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes: La tercera etapa del proyecto es el primer *release*. Dura entre X y X semanas. -Más allá de que en cada iteración produzcas 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: +Más allá de que en cada iteración produzcas una [solución +consumible](/4_Conceptos/4_Solucion_consumible.md), 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 From 5968a64a8eeb77ffc91054ccd57af5bcd5d948cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fernando=20Machado=20P=C3=ADriz?= Date: Wed, 12 Jun 2024 18:46:54 -0300 Subject: [PATCH 17/18] Renamed file to match h2 --- ...{3_5_Aceptacion_cliente.md => 3_5_Carta_aceptacion_cliente.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename 3_Plantillas/{3_5_Aceptacion_cliente.md => 3_5_Carta_aceptacion_cliente.md} (100%) diff --git a/3_Plantillas/3_5_Aceptacion_cliente.md b/3_Plantillas/3_5_Carta_aceptacion_cliente.md similarity index 100% rename from 3_Plantillas/3_5_Aceptacion_cliente.md rename to 3_Plantillas/3_5_Carta_aceptacion_cliente.md From 47d2ee439c7b13cf08caf3c86e6c5f04147179d8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fernando=20Machado=20P=C3=ADriz?= Date: Wed, 12 Jun 2024 18:49:11 -0300 Subject: [PATCH 18/18] Apply suggestions from code review Co-authored-by: Paolo Mazza <47277080+PaoloMazza1204@users.noreply.github.com> --- 3_Plantillas/3_7_Compromiso_confidencialidad.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/3_Plantillas/3_7_Compromiso_confidencialidad.md b/3_Plantillas/3_7_Compromiso_confidencialidad.md index cea582c..7c9b3ff 100644 --- a/3_Plantillas/3_7_Compromiso_confidencialidad.md +++ b/3_Plantillas/3_7_Compromiso_confidencialidad.md @@ -1,6 +1,6 @@ # 3 Plantillas -## 3.x Compromiso de confidencialidad +## 3.7 Compromiso de confidencialidad Este es un documento de confidencialidad más completo que la [carta de confidencialidad simple](/3_Plantillas/3_6_Carta_confidencialidad_simple.md) y lo firma