Revisión actual del 18:35 14 jul 2024

Introducción

Objetivos generales

El objetivo general del proyecto es que el equipo ponga en práctica y observe cómo se ponen en funcionamiento en un proyecto real todos los conceptos teórico-prácticos que se vean en la asignatura y profundice en ellos todo lo que su motivación lo lleve.

Este es un proyecto en el que, para llevarlo a cabo de manera satisfactoria, será muy útil tener buenas dosis de entusiasmo e interés en la temática del proyecto. En este sentido, se da un amplio margen de libertad para elegir la temática, el proyecto, las herramientas, la tecnología,... por lo tanto, ¡elige lo que más te guste!.

De los entregables se espera tengan un acabado profesional. La puntualidad, rigor y seriedad en las entregas serán valores irrenunciables sin los que no podrá llevarse el trabajo adelante. No llevar a cabo los procesos y entregables con puntualidad tendrá penalización en la nota. Hacer unos entregables profesionales y rigurosos tendrá valor en la nota.

Tareas para la realización

De manera general las tareas para la realización del trabajo serán los siguientes:

Conformar e inscribir el equipo.
Elegir el proyecto a realizar.
Establecer con claridad la organización y coordinación del equipo y el mecanismo de comunicación tanto interno como externo que se va a tener en el equipo. Muchos de los problemas que se encuentran en el desarrollo de este proyecto no son tanto técnicos como organizativos.
Ir elaborando un entorno con las herramientas que se usan o se podrían usar en el proyecto.
Planificar las iteraciones tanto internas como los milestones externos.
Elaborar una documentación profesional siguiendo las indicaciones de este documento y los enlaces asociados.
Elaborar entornos de despliegue para entregar.
Elaborar un diario del grupo a lo largo de todo el proceso.
Empaquetar todo para la entrega y entregar.

Equipos

Conformación

El proyecto debe ser realizado en equipo. Se hará un taller para ver afinidades de personas y disponibilidades horarias para conformar los equipos un día en clases de teoría al inicio del cuatrimestre. En todo caso, este taller no es vinculante y servirá únicamente para promover la creación de equipos. Es responsabilidad de cada alumno/a buscar un equipo que le interese y se acerque a sus expectativas y motivaciones. Sólo en casos extremos, se acudirá al coordinador de la asignatura para que le asigne un equipo a un alumno/a.

Se recomienda que se busquen en el equipo que sean afines en intereses, horarios y forma de trabajo pero al mismo tiempo complementarios.

Número de proyectos y subproyectos

Se conformarán distintos tipos de proyectos. Cada proyecto derivado de UVLHub tendrá un nombre que será el que se use para identificarlo siguiendo un patrón.

En el curso 2024/2025 los nombres de los proyectos deben seguir este patrón: [plato andaluz]-hub, por ejemplo salmorejo-hub. Si el proyecto tiene más de un equipo, se pondrá un número natural a continuación del nombre siguiento el patrón [plato andaluz]-hub-N, por ejemplo, salmorejo-hub-1 y salmorejo-hub-2.

En el caso de proyectos InnoSoft, ver las indicaciones en el apartado correspondiente.

Número de componentes

Los equipos de trabajo deben estar conformados idealmente por 6 personas salvo circunstancias excepcionales en los que se podrá reducir este número. En ningún caso se podrá aumentar el número de integrantes del equipo.

Si en el transcurso de la asignatura algún miembro del equipo abandona, este abandono debe ser notificado al coordinador de proyectos de la asignatura y quedar reflejado en el diario del equipo constando la firma y aprobación de los restantes miembros del equipo y si fuera posible de la persona que abandona el equipo. Si después de distribuir a todos/as los alumnos/as se quedase un equipo con un número distinto a los márgenes establecidos, la incidencia se resolverá junto con la/el delegada/o de la clase o interlocutor válido y el coordinador de proyectos de la asignatura.

Coordinación del equipo

Habrá al menos un coordinador/a del equipo y como máximo dos que serán quienes lleven la coordinación en el equipo en cuanto a tiempos, tareas y gestiones. También llevará las tareas de coordinación con el resto de equipos. No se debe confundir ser coordinador con ser jefe. Ver tema de gestión de equipos visto en la asignatura

Los coordinadores de los distintos equipos deben comunicarse entre ellos para aclarar cualquier cuestión de coordinación que sea necesaria entre los equipos que conforman un mismo proyecto.

Reparto de tareas del equipo

Todos los componentes del equipo deben ser desarrolladores en el proyecto. Por ejemplo, no se puede dividir el equipo para que unos hagan desarrollo y otros hagan documentación. Para poder poner en práctica los conocimientos debe todo el mundo ser desarrollador/a y trabajar en otras tareas en paralelo. Se podrá cargar más en una persona u otra la parte de desarrollo pero en ningún caso se podrá quitar a alguien de esta labor.

Fecha límite de inscripción

La fecha límite para inscribir los equipos será el primer viernes de Octubre. Para inscribir los equipos siga las instrucciones que se den en la wiki. En todo caso, esa es la fecha límite para inscribir el equipo pero desde antes debe estar conformado para poder ir trabajando en el proyecto.

El equipo de inscribirá siguiendo el patrón de nombres descrito anteriormente para poder identificarlos y usando las etiquetas que corresponden con el grupo al que pertenece el proyecto.

Gestión de conflictos

El equipo escribirá un “acta funcional” en la que se establezcan de manera clara, pero sintética, cuáles van a ser los acuerdos que van a regir el funcionamiento del equipo. Debe incluir una serie de “sanciones” en caso del incumplimiento de dichos acuerdos. Dicha acta fundacional será firmada por todos los miembros del equipo al inicio del proyecto y será entregada en el primer milestone (M1). El acta puede ser revisada con acuerdo de los componentes pero esto se hará de manera excepcional.

Se tendrá una actitud positiva en el equipo de trabajo pero eso no quitará que en algún momento se pueda dar y seguramente se de algún tipo de conflicto. En caso de conflicto “grave” se acudirá cuanto antes al coordinador de proyectos de la asignatura para que sepa ayudar a reconducir o resolver el conflicto de modo que no perjudique a ninguna de las partes. Tipos de conflictos frecuentes:

Ejemplo de conflictos frecuentes
Conflicto	Acción a realizar
Algún miembro del equipo no trabaja, no acude a las reuniones, no contesta a los mensajes, no presta interés en el equipo, etcétera.	Tener previstas este tipo de situaciones en el acta funcional. Poner un límite prudente a esta situación y no dejar pasar el tiempo. Hacer constar en acta la situación y comunicarlo al coordinador para, en su caso, dar de baja al miembro del equipo o intentar mediar en el conflicto.
Se tienen puntos de vista distintos sobre determinados temas del trabajo.	Esto es muy frecuente en un equipo de trabajo por lo que es una situación que deben superar y sólo en caso extremo acudirán al coordinador para que, en su caso, medie en el conflicto
Hay niveles distintos de interés/habilidades en el equipo y eso hace que haya partes que se hagan mejor y otras peor.	El coordinador del equipo debe intentar solventar esta situación y, en todo caso, será algo frecuente en el trabajo por lo que las personas con más interés deben atraer el interés de las personas que tengan menos para así acompañarlas, motivarlas y hacerlas aprender pues enseñando también se aprende. El liderazgo no consiste solo en saber trabajar bien y exigir que el resto lo haga, también saber motivar, acompañar y cooperar con el resto es un síntoma de buen liderazgo.

Temática

Objetivo del proyecto

El objetivo del trabajo es que el equipo observe, entienda y decida sobre los procesos, técnicas y herramientas relacionados con los temas de la asignatura. Para ello trabajará a lo largo del cuatrimestre con objeto de abordar un proyecto en equipo que cumpla con los requisitos que se enuncian en este apartado y otras secciones de la wiki. Se trata de que el equipo trabaje con código ya desarrollado y proponga cambios sobre el proyecto que redunden en alguna mejora del mismo.

Elección del proyecto

Se propondrán distintos subsistemas que parten de un código ya desarrollado al que habrá que introducir cambios para que el proyecto evolucione y tengan que hacerse tareas de evolución y gestión de la configuración.

Cada curso habrá una sesión de discusión de los proyectos disponibles y de cómo organizar los distintos subsistemas y equipos.

Evolución y cambios en el proyecto

El equipo debe proponer cuáles son los cambios que va a introducir al proyecto que podrían ser, aunque no están limitados a, alguno o varios de los siguientes:

cambio completo en el entorno tecnológico usado, justificando dicho cambio
corrección de errores
añadir nueva funcionalidad
refactorizar el código, es decir, cambiar alguna parte de la aplicación sin modificar su funcionalidad
sustituir algún elemento con el que interactúe la aplicación como, por ejemplo, la base de datos o el servidor en el que se despliegue.
añadir casos de prueba

Debe haber al menos un work item por miembro del equipo, es decir, cada miembro del equipo deberá hacerse cargo de al menos un work item principal que podrá ser dividido en Work Items (WIs) más pequeños. Estos WIs no tienen por qué ser secuenciales en el tiempo y podrían desarrollarse en paralelo.

Evite hacer cambios que no tienen valor añadido. Mejor hacer pocos cambios y bien hechos que muchos cambios sin mucho sentido.

Cada WI debe ser coherente y debe desarrollar al menos una historia de usuario que pueda ser probada en el sistema.

Evite los WIs que no tengan que ver los unos con los otros. Lo ideal es que los WIs tengan interacciones y dependencias entre ellos. Así podrá sacar más partido a lo aprendido en la asignatura.

Entregables

El trabajo elaborado por el equipo tendrá una serie de entregables. En los siguientes apartados se describen cuáles serán esos entregables y los apartados que tienen que contener.

Tenga muy en cuenta que a la hora de entregar el documento no podrá “copiar y pegar” de fuentes sin reconocer las mismas, es decir, no se permite el plagio y el plagiar será motivo de suspenso inmediato.

En caso de copiar un texto de manera literal se deberá reconocer la fuente desde la que se ha copiado y para ello, la frase copiada se pondrá entre comillas y cursiva y se pondrá una referencia o cita a su origen, por ejemplo así:

“Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed as part of extreme programming (XP)” (tomado de http://en.wikipedia.org/wiki/Continuous_integration)

El plagio también afecta al código fuente de un proyecto software por lo que debe tener en cuenta que no podrá plagiar código fuente tampoco. Podrá reutilizarlo siempre que la licencia de software que tenga dicho código lo permita.

Si necesita saber más sobre cómo evitar el plagio, visite este enlace: http://guiasbus.us.es/bibliografiaycitas/comoevitarplagio

A continuación se describen cuáles son los entregables del proyecto.

Documento del proyecto

Ver esta página para más información sobre el documento del proyecto: https://github.com/EGCETSII/Entregables/wiki/Documento-del-proyecto

Entornos de despliegue

Se deberá entregar o intentar hacer accesible el entorno de despliegue que contengan todos los elementos necesarios para trabajar con el proyecto.

Se recomienda usar un servidor de despliegue para poder desplegar la plataforma completa y tenerla accesible para la evaluación. En todo caso, siga las indicaciones vistas durante las prácticas.

Diario del equipo

El equipo debe gestionar un documento como diario del equipo en el que se vayan reflejando todas las decisiones importantes del mismo. Este diario puede llevarse de manera digital o física a decisión del equipo y para ello puede usarse cualquier herramienta que se considere necesaria.

En cualquier caso el diario será uno de los entregables al final del proyecto. Debe contener las actas de las reuniones y las decisiones importantes que se tomaron.

Siga las instrucciones de cómo realizar el diario del equipo en la siguiente dirección: https://github.com/EGCETSII/Entregables/wiki/Diario-del-Equipo

Además de decir cuándo se han tomado las decisiones importantes, añadir qué tiempos y tareas se decidieron y qué imputación en horas real se ha hecho para cada uno de los miembros del equipo.

En caso se haber diferencias significativas, se debe hacer un agregado por miembros del grupo y el total de horas imputadas. De no haber diferencias explícitas se considerará que todos los miembros del proyecto han aportado por igual. Si se quieren hacer diferencias, sería conveniente hacer algo que desglose de mutuo acuerdo el grado de implicación en el proyecto en una escala de 1 a 10. Si esto no está puesto explícitamente, se considerará que todos han trabajado de manera similar.

¡OJO! Esta escala es una ponderación del trabajo, no es una nota, es decir, si alguien pone que ha trabajado un valor de 10, significa que ha empleado el 100% del tiempo acordado en el proyecto mientras que si alguien pone un 6 sería un 60%. No es la nota del proyecto que estima el alumno que merecería.

Si es posible, incluir una foto de cada miembro del equipo al lado de su nombre.

Evaluación

Ponderación

El proyecto tendrá una ponderación que se anunciará para cada curso. Por lo general, una asignación de un X% de la nota final de la asignatura para el proyecto, tiene asociada una carga de trabajo de X horas de trabajo, por lo que si tiene asignado, por ejemplo, un peso de un 60% de la nota, se le deberá dedicar, aproximadamente, 60 horas de trabajo al proyecto para asegurar que se supera.

Actividad del proyecto

Se debe estar en torno a los siguientes indicadores de la actividad del proyecto para efectuar los cambios de evolución descritos anteriormente. Tenga en cuenta que esto son indicadores y por lo tanto no son datos totalmente rígidos pero sirven para dar una indicación de la dimensión del proyecto que se espera. Los cambios, al final, supondrán al menos:

4 líneas de código aproximadamente por miembro del equipo y hora asignada al proyecto de modo que, por ejemplo, si se tienen asignadas al proyecto 60 horas, se deberían hacer al menos 240 líneas de código.
0,2 commits por miembro del equipo y hora. Por ejemplo, si se tienen asignadas 60 horas, se deberían hacer al menos 12 commits por persona.
0,1 incidencias por miembro del equipo y hora. Por ejemplo, si se tienen asignadas 60 horas, se deberían hacer al menos 6 incidencias por persona.
0,1 pruebas por miembro del equipo y hora. Por ejemplo, si se tienen asignadas 60 horas, se deberían hacer al menos 6 pruebas por persona.

Aunque el principal objetivo del trabajo no es evaluar el qué sino el cómo, sí es necesario tener un número de cambios suficiente como para abordar el proyecto lo cuál se dimensionará por estos indicadores y por el proyecto global en sí.

Sesiones de seguimiento y entrega

Habrá dos tipos de sesiones en la que se trabajará sobre el proyecto:

Sesiones de seguimiento: en las sesiones de seguimiento se trabaja sobre el proyecto y se hace un seguimiento del mismos pero no hay entregas formales. Se valorará la asistencia y participación y esto tendrá un peso en la nota.
Sesiones de entrega: en dichas sesiones no se hace seguimiento en forma de tutoría. Se presentan, defienden y entregan los elementos que correspondan al milestone correspondiente. En este caso la asistencia es obligatoria y hay una nota asociada a dicha entrega.

Notas

Uno de los objetivos importantes del proyecto es que los equipos tengan que interactuar entre ellos y por lo tanto sepan evolucionar conjuntamente el proyecto. Es por eso que se va a premiar si los equipos son capaces de interactuar entre ellos. Para ello se han establecido umbrales para los distintos escenarios que se describen en la página wiki.

Los detalles de las notas y las poderaciones serán publicados en el apartado correspondiente.

Al ser un proyecto de evaluación global, la nota final del proyecto se publicará luego de la última entrega pues se evalúa el proyecto en su conjunto y su evolución.

@@ Línea 1: / Línea 1: @@
+[[Página_Principal]] -> [[Proyecto - 24/25]]
 = Introducción =
@@ Línea 36: / Línea 38: @@
 == Número de proyectos y subproyectos ==
-Se conformarán distintos tipos de proyectos. Cada proyecto derivado de UVLHub tendrá un nombre que será el que se use para identificarlo siguiendo este patrón: decide-apodo. Siendo ''apodo'' una palabra elegida en torno a un conjunto de palabras similares, por ejemplo, pueblos de Andalucía: decide-lebrija, decide-albolote,...
+Se conformarán distintos tipos de proyectos. Cada proyecto derivado de UVLHub tendrá un nombre que será el que se use para identificarlo siguiendo un patrón.
 En el curso 2024/2025 los nombres de los proyectos deben seguir este patrón: [plato andaluz]-hub, por ejemplo salmorejo-hub. Si el proyecto tiene más de un equipo, se pondrá un número natural a continuación del nombre siguiento el patrón [plato andaluz]-hub-N, por ejemplo, salmorejo-hub-1 y salmorejo-hub-2.
 En el caso de proyectos InnoSoft, ver las indicaciones en el apartado correspondiente.

Diferencia entre revisiones de «Guía general del proyecto en equipo»