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

De Wiki de EGC
Saltar a: navegación, buscar
(Página creada con « = 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 proyect...»)
 
(Número de proyectos y subproyectos)
 
(No se muestran 25 ediciones intermedias de 2 usuarios)
Línea 1: Línea 1:
 +
[[Página_Principal]] -> [[Proyecto - 24/25]]
 +
  
 
= Introducción =
 
= Introducción =
Línea 8: Línea 10:
 
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!'''.
 
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!'''.
  
 +
<div style="background-color:rgb(255,204,77); padding: 10px;">
 
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.
 
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.
 +
</div>
  
 
== Tareas para la realización ==
 
== Tareas para la realización ==
Línea 14: Línea 18:
 
De manera general las tareas para la realización del trabajo serán los siguientes:
 
De manera general las tareas para la realización del trabajo serán los siguientes:
  
* Conformar e inscribir el equipo (ver Sección [[#ch-grupos|2]]).
+
* Conformar e inscribir el equipo.
* Elegir el proyecto a realizar (ver Sección [[#sec-eleccion|3.2]]).
+
* 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.
 
* 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.
 
* Ir elaborando un entorno con las herramientas que se usan o se podrían usar en el proyecto.
Línea 32: Línea 36:
 
Se recomienda que se busquen en el equipo que sean afines en intereses, horarios y forma de trabajo pero al mismo tiempo complementarios.
 
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 ==
+
== Número y nombre de proyectos y subproyectos ==
 
 
En el curso 2023/2024 se conformarán distintos tipos de proyectos (ver la wiki sobre este aspecto). La forma de decidir qué formato seguir, será anunciada también en la wiki.
 
  
Cada proyecto derivado de Decide 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.
  
De cada proyecto derivado de Decide habrá suproyectos para cada subsistema (podrían haber subproyectos que quedaran desiertos) y que llevarán el nombre de decide-apodo-N, siendo N un número natural, por ejemplo, decide-guadalquivir-1, decide-guadalquivir-2, etcétera..
+
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.
  
Además, se identificará el proyecto como el tipo de proyecto que se esté realizando. Para más indicaciones concretas de cómo hacer la composición del nombre del equipo leer la wiki de la asignatura.
+
En el caso de proyectos InnoSoft, ver las indicaciones en el apartado correspondiente.
  
 
== Número de componentes ==
 
== Número de componentes ==
Línea 50: Línea 52:
 
=== Coordinación del equipo ===
 
=== 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''.<ref>Ver tema de gestión de equipos visto en la asignatura</ref>
+
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.
 
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.
Línea 60: Línea 62:
 
== Fecha límite de inscripción ==
 
== Fecha límite de inscripción ==
  
 +
<div style="background-color:rgb(255,204,77); padding: 10px;">
 
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.
 
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 en la Sección [[#sec-proy|2.2]] para poder identificarlos y usando las etiquetas que corresponden con el grupo al que pertenece 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.
 +
</div>
  
 
== Gestión de conflictos ==
 
== Gestión de conflictos ==
Línea 70: Línea 74:
 
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:
 
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:
  
* 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.
+
{| class="wikitable" style="margin:auto"
* 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.
+
|+ Ejemplo de conflictos frecuentes
 
+
|-
* Se tienen puntos de vista distintos sobre determinados temas del trabajo.
+
! '''Conflicto''' !! '''Acción a realizar'''
* 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.
+
|-
 +
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.
  
* 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.
+
| 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 =
 
= Temática =
Línea 83: Línea 92:
 
== Objetivo del proyecto ==
 
== 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 documento y en 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.
+
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 ==
 
== Elección del proyecto ==
Línea 90: Línea 99:
  
 
Cada curso habrá una sesión de discusión de los proyectos disponibles y de cómo organizar los distintos subsistemas y equipos.
 
Cada curso habrá una sesión de discusión de los proyectos disponibles y de cómo organizar los distintos subsistemas y equipos.
 
El grupo podrá elegir entre dos opciones: <math display="inline">i)</math> trabajar sobre un proyecto real <math display="inline">ii)</math> trabajar sobre un proyecto desarrollado en el curso anterior.
 
 
=== Proyecto real ===
 
 
Al inicio del curso estarán disponibles en la WIKI algunas propuestas de proyectos para trabajar sobre el sistema real. Cabe señalar que en caso de elegir esta propuesta se puede optar también a participar en el concurso de software libre.<ref>https://www.concursosoftwarelibre.org/</ref>
 
 
=== Proyecto de cursos anteriores ===
 
 
El grupo debe elegir un proyecto de los desarrollados en cursos anteriores para su estudio, análisis, documentación y toma de decisiones.
 
  
 
== Evolución y cambios en el proyecto ==
 
== Evolución y cambios en el proyecto ==
Línea 112: Línea 111:
 
* añadir casos de prueba
 
* añadir casos de prueba
  
'''Debe haber al menos una iteración funcional por miembro del equipo''', es decir, cada miembro del equipo deberá hacerse cargo de al menos un incremento funcional. Estos incrementos no tienen por qué ser secuenciales en el tiempo y podrían desarrollarse en paralelo.
+
<div style="background-color:rgb(255,204,77); padding: 10px;">
 +
'''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.
 
Evite hacer cambios que no tienen valor añadido. Mejor hacer pocos cambios y bien hechos que muchos cambios sin mucho sentido.
  
Cada cambio funcional debe ser coherente y debe desarrollar al menos una historia de usuario que pueda ser probada en el sistema.
+
Cada WI debe ser coherente y debe desarrollar al menos una historia de usuario que pueda ser probada en el sistema.
  
Evite los incrementos funcionales que no tengan que ver los unos con los otros. Lo ideal es que los incrementos funcionales tengan interacciones y dependencias entre ellos. Así podrá sacar más partido a lo aprendido en la asignatura.
+
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.
 +
</div>
  
 
= Entregables =
 
= Entregables =
Línea 124: Línea 125:
 
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.
 
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.
  
 +
<div style="background-color:rgb(255,204,77); padding: 10px;">
 
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.
 
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.
 +
</div>
  
 
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í:
 
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)”''<ref>tomado de http://en.wikipedia.org/wiki/Continuous_integration</ref>
+
''“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.
 
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
 
Si necesita saber más sobre cómo evitar el plagio, visite este enlace: http://guiasbus.us.es/bibliografiaycitas/comoevitarplagio
 +
 +
Sobre el uso de herramientas de inteligencia artificial, está permitido, pero debe señalar en la documentación cómo ha hecho y para qué ha hecho uso de dichas herramientas y deberá ser capaz de defender tanto lo escrito como lo programado (en su caso) por parte de dichas herramientas.
  
 
A continuación se describen cuáles son los entregables del proyecto.
 
A continuación se describen cuáles son los entregables del proyecto.
Línea 156: Línea 161:
 
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.
 
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.
  
 +
<div style="background-color:rgb(255,204,77); padding: 10px;">
 
'''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.
 
'''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.
 +
</div>
 +
  
 
'''¡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.
 
'''¡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.
 
Si es posible, incluir una foto de cada miembro del equipo al lado de su nombre.
 
== ''Milestones'' intermedios ==
 
 
Los equipos deberán cumplir una serie de ''milestones'' intermedios definidos al inicio del curso y publicados en la <code>Wiki</code> de la asignatura. Se explicitará con la debida antelación lo que tienen que tener preparado para cada sesión.
 
 
== Fecha para la entrega ==
 
 
Se anunciará en la <code>Wiki</code> de la asignatura una entrega final y las entregas intermedias para los milestones.
 
  
 
= Evaluación =
 
= Evaluación =
Línea 174: Línea 174:
 
== Ponderació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 carta de trabajo de <math display="inline">X</math> 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.
+
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 ==
 
== Actividad del proyecto ==
Línea 180: Línea 180:
 
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:
 
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:
  
 +
<div style="background-color:rgb(255,204,77); padding: 10px;">
 
* 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.
 
* 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,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 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.
 
* 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.
 +
</div>
  
 
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í.
 
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í.
Línea 198: Línea 200:
 
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.
 
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 la wiki de la asignatura.
+
Los detalles de las notas y las poderaciones serán publicados en el apartado correspondiente.
 
 
Al ser un proyecto de evaluación continua, 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.
 
  
<references />
+
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.

Revisión actual del 17:33 23 sep 2024

Página_Principal -> Proyecto - 24/25


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 y nombre 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

Sobre el uso de herramientas de inteligencia artificial, está permitido, pero debe señalar en la documentación cómo ha hecho y para qué ha hecho uso de dichas herramientas y deberá ser capaz de defender tanto lo escrito como lo programado (en su caso) por parte de dichas herramientas.

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.