Diferencia entre revisiones de «Guia-proyecto»
De Wiki de EGC
(→Sobre el proyecto en sí:) |
(→Sobre la gestión de work items:) |
||
| (No se muestran 4 ediciones intermedias del mismo usuario) | |||
| Línea 1: | Línea 1: | ||
| − | [[Página_Principal]] -> [[Proyecto - | + | [[Página_Principal]] -> [[Proyecto - 24/25]] |
==Mínimos para superar el proyecto == | ==Mínimos para superar el proyecto == | ||
| Línea 9: | Línea 9: | ||
* No pueden presentarse como proyectos subsistemas aislados en los que se evoluciona una parte y se deja atrás el resto. Por ejemplo, no se aceptarán proyectos que añadan distintos formatos de exportaciones de modelos pero luego no tenga ningún tipo de integración con otros elementos | * No pueden presentarse como proyectos subsistemas aislados en los que se evoluciona una parte y se deja atrás el resto. Por ejemplo, no se aceptarán proyectos que añadan distintos formatos de exportaciones de modelos pero luego no tenga ningún tipo de integración con otros elementos | ||
| − | === Sobre la gestión de incidencias:=== | + | === Sobre la gestión de cambio e incidencias sobre work items:=== |
| − | * Debe tener un proceso de gestión de | + | * Debe tener un proceso de gestión de Work Items (WIs) en el que los WIs pasen por una serie de estados, sean de una serie de tipos, tengan asignados unos roles en su gestión y una prioridad. |
| − | * Debe tener una plantilla para | + | * Debe tener una plantilla para los WIs y esa plantilla debe ser usada de manera homogenea al menos en los WIs más cercanas a la entrega. |
=== Sobre la gestión del código: === | === Sobre la gestión del código: === | ||
* Debe haber borrado el historial de commits anterior del proyecto antes de que el equipo haya empezado a evolucionarlo. | * Debe haber borrado el historial de commits anterior del proyecto antes de que el equipo haya empezado a evolucionarlo. | ||
| + | * Los commits deben hacerse con el mismo nombre de usuario para cada componente del equipo. Si hay N componentes, debe haber N nombres de usuarios. Por cada nombre de usuario adicional se penalizará. | ||
* Debe tener un repositorio de código en el que se haya guardado toda la historia del proyecto. | * Debe tener un repositorio de código en el que se haya guardado toda la historia del proyecto. | ||
* Debe tener al menos los commits que se indican en el enunciado y una participación homogénea de commits por parte de todos los componentes del equipo. | * Debe tener al menos los commits que se indican en el enunciado y una participación homogénea de commits por parte de todos los componentes del equipo. | ||
| Línea 25: | Línea 26: | ||
* Debe tener un servidor de integración continua funcionando y conectado con el repositorio de código. | * Debe tener un servidor de integración continua funcionando y conectado con el repositorio de código. | ||
| − | * Debe tener al menos un script de construcción y que dicho script sea personalizado con respecto a su proyecto (se verá mal que el script sea el mismo que el del proyecto | + | * Debe tener al menos un script de construcción y que dicho script sea personalizado con respecto a su proyecto (se verá mal que el script sea el mismo que el del proyecto original). |
| − | * Debe tener integradas pruebas. | + | * Debe tener integradas pruebas. |
=== Sobre las pruebas automáticas: === | === Sobre las pruebas automáticas: === | ||
Revisión actual del 20:20 2 nov 2024
Página_Principal -> Proyecto - 24/25
Contenido
Mínimos para superar el proyecto
El proyecto de EGC es un proyecto que tiene muchos elementos que se pueden y deben evaluar por lo que su evaluación depende mucho del tipo de proyecto, de la envergadura, de su complejidad, etcétera. De todos modos, entre los tutores, hemos acordado un conjunto de criterios mínimos para poder superar el proyecto. Superar el proyecto para nosotros significa tener una nota entre 4 y 5 al menos.
Sobre el proyecto en sí:
- Debe presentar un proyecto funcional que realice un ciclo funcional completo y que pueda usarse (a pesar de que tenga algunos elementos de mejora)
- No pueden presentarse como proyectos subsistemas aislados en los que se evoluciona una parte y se deja atrás el resto. Por ejemplo, no se aceptarán proyectos que añadan distintos formatos de exportaciones de modelos pero luego no tenga ningún tipo de integración con otros elementos
Sobre la gestión de cambio e incidencias sobre work items:
- Debe tener un proceso de gestión de Work Items (WIs) en el que los WIs pasen por una serie de estados, sean de una serie de tipos, tengan asignados unos roles en su gestión y una prioridad.
- Debe tener una plantilla para los WIs y esa plantilla debe ser usada de manera homogenea al menos en los WIs más cercanas a la entrega.
Sobre la gestión del código:
- Debe haber borrado el historial de commits anterior del proyecto antes de que el equipo haya empezado a evolucionarlo.
- Los commits deben hacerse con el mismo nombre de usuario para cada componente del equipo. Si hay N componentes, debe haber N nombres de usuarios. Por cada nombre de usuario adicional se penalizará.
- Debe tener un repositorio de código en el que se haya guardado toda la historia del proyecto.
- Debe tener al menos los commits que se indican en el enunciado y una participación homogénea de commits por parte de todos los componentes del equipo.
- Debe tener un patrón a la hora de hacer commits y este debe haber sido usado de manera homogénea al menos en las etapas finales del proyecto.
- No debe tener en control de versiones los ficheros de configuración de los IDEs ni otro tipo de información que no corresponde como credenciales de acceso a APIs, bases de datos, etcétera.
Sobre la gestión de la construcción e integración continua:
- Debe tener un servidor de integración continua funcionando y conectado con el repositorio de código.
- Debe tener al menos un script de construcción y que dicho script sea personalizado con respecto a su proyecto (se verá mal que el script sea el mismo que el del proyecto original).
- Debe tener integradas pruebas.
Sobre las pruebas automáticas:
- Debe tener tantas pruebas por miembro del equipo como se señala en el enunciado.
- Debe tener al menos pruebas funcionales unitarias.
Sobre el despliegue:
- Debe tener desplegado el sistema de manera local (con run server o similar).
- Debe tener desplegado el sistema o al menos con una de las siguientes opciones: contenedores (docker) o máquinas virtuales (Vagrant) o de manera remota (con heroku, render o similar).
