Diferencia entre revisiones de «Guia-proyecto»
De Wiki de EGC
(Página creada con «Página_Principal -> 2020/2021 -> Proyecto - 20/21 '''En construcción''' En esta página se da una guía de qué aspectos cuidar y cómo con referencia al pro...») |
|||
| Línea 1: | Línea 1: | ||
[[Página_Principal]] -> [[2020/2021]] -> [[Proyecto - 20/21]] | [[Página_Principal]] -> [[2020/2021]] -> [[Proyecto - 20/21]] | ||
| − | + | ==Mínimos para superar el proyecto == | |
| − | |||
| − | ==Sobre los | + | 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 la gestión de incidencias:=== | ||
| + | |||
| + | * Debe tener un proceso de gestión de incidencias en el que las incidencias 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 las incidencias y esa plantilla debe ser usada de manera homogenea al menos en las incidencias más cercanas a la entrega. | ||
| + | |||
| + | === Sobre la gestión del código: === | ||
| + | |||
| + | * 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 homogenea 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 homogenea 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 Decide). | ||
| + | * 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 de manera remota (con heroku o similar). | ||
| + | * Debe tener desplegado el sistema o al menos con una de las siguientes opciones: contenedores (docker o podman) o máquinas virtuales (Vagrant) | ||
Revisión del 20:34 5 ene 2021
Página_Principal -> 2020/2021 -> Proyecto - 20/21
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 la gestión de incidencias:
- Debe tener un proceso de gestión de incidencias en el que las incidencias 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 las incidencias y esa plantilla debe ser usada de manera homogenea al menos en las incidencias más cercanas a la entrega.
Sobre la gestión del código:
- 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 homogenea 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 homogenea 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 Decide).
- 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 de manera remota (con heroku o similar).
- Debe tener desplegado el sistema o al menos con una de las siguientes opciones: contenedores (docker o podman) o máquinas virtuales (Vagrant)
