Diferencia entre revisiones de «Guia-proyecto»

Revisión actual del 12:18 7 dic 2023

Página_Principal -> Proyecto - 22/23

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 algoritmos de recuento de votos si no están integrados con el resto del sistema de votación.

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 haber borrado el historial de commits anterior del proyecto antes de que el equipo haya empezado a evolucionarlo.
• 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 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 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).