|
|
| (No se muestran 36 ediciones intermedias de 2 usuarios) |
| Línea 1: |
Línea 1: |
| − | * Bajar el archivo en PDF: [[Archivo:TrabajoEGC.pdf|Enunciado del trabajo en grupo]]
| + | = Enunciado del trabajo: = |
| | | | |
| − | {Introducción}
| + | Bajar el archivo PDF: [[Archivo:TrabajoEGC.pdf|Enunciado del trabajo en grupo]] |
| | | | |
| − | = Objetivos generales = | + | = Sobre la primera entrega = |
| | | | |
| − | El objetivo general del trabajo es que el grupo ponga en práctica y observe cómo se ponen en funcionamiento en 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.
| + | * [[Comentarios y notas primera entrega 2014]] |
| − | | + | * [[Comentarios a los grupos 2014]] |
| − | Este es un trabajo en el que, para llevarlo a cabo de manera satisfactoria, será muy útil tener buenas dosis de entusiamo e interés en la temática del trabajo. En este sentido, se da un amplio márgen de libertad para elegir la temática, el proyecto, las herramientas, la tecnología,... por lo tanto, '''¡elige lo que más te apasione!'''.
| + | * [[Comentarios y notas provisionales 2014]] |
| − | | |
| − | Los entregables serán entregables que se espera tengan un acabado profesional. La puntualidad, rigor y seriedad en las entregas y los entregables será un valor irrenunciable sin el que no podrá llevarse el trabajo adelante.
| |
| − | | |
| − | = Tareas para la realización =
| |
| − | | |
| − | De manera general las tareas para la realización del trabajo serán los siguientes:
| |
| − | | |
| − | * Conformar e inscribir el grupo (ver Sección ch-grupos).
| |
| − | * Elegir el proyecto a realizar (ver Sección sec-eleccion).
| |
| − | * Ir estudiando los aspectos vistos en clases y observando cómo el proyecto elegido trata dichos aspectos e ir documentando gradualmente esos aspectos. Ir pensando en alternativas, mejoras, etcétera. | |
| − | * Ir elaborando un entorno con las herramientas que se usan o se podrían usar en el proyecto.
| |
| − | * Elaborar una documentación profesional siguiendo las indicaciones de este documento.
| |
| − | * Elaborar una máquina virtual con todo el entorno a entregar. | |
| − | * Elaborar un diario del grupo.
| |
| − | * Empaquetar todo para la entrega y entregar.
| |
| − | | |
| − | {Grupos}(ch-grupos)
| |
| − | | |
| − | = Conformación =
| |
| − | | |
| − | (sec-org-grupo)
| |
| − | | |
| − | El trabajo debe ser realizado en grupo. Se hará un taller para ver afinidades de personas y disponibilidades horarias para conformar los grupos 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 del grupo. '''Es responsabilidad de cada alumno/a buscar un grupo''' que le interese y se acerque a sus espectativas e intereses. Sólo en casos extremos, se acudirá al coordinador de la asignatura para que le asigne un grupo a un alumno/a.
| |
| − | | |
| − | Se recomienda que se busquen en el grupo que sean afines en intereses, horarios y forma de trabajo.
| |
| − | | |
| − | = Número de componentes =
| |
| − | | |
| − | (sec-num)
| |
| − | | |
| − | Los grupos de trabajo deben estar conformados por un '''mínimo de 3 personas y un máximo de 6'''. Si en el transcurso de la asignatura algún miembro del grupo abandona el grupo, este abandono debe ser notificado al coordinador de la asignatura y quedar reflejado en el diario del grupo constando la firma y aprobación de los restantes miembros del grupo y si fuera posible de la persona que abandona el grupo.
| |
| − | | |
| − | = Fecha límite de inscripción =
| |
| − | | |
| − | (sec-deadline)
| |
| − | | |
| − | La fecha límite para inscribir los grupos será el '''último viernes de Octubre'''. Para inscribir los grupos ser usará el portal de grupos disponible en: https://opera-portal.us.es/egc.
| |
| − | | |
| − | = Gestión de conflictos =
| |
| − | | |
| − | (sec-conflictos)
| |
| − | | |
| − | Se tendrá una actitud positiva en el grupo 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á cuánto antes al coordinador de la asignatura para que sepa ayudar a reconducir o resolver el conflicto de modo que no perjudique a ninguna de las partes.
| |
| − | | |
| − | {Temática}
| |
| − | | |
| − | = Objetivo del trabajo =
| |
| − | | |
| − | (sec-obj)
| |
| − | | |
| − | El objetivo del trabajo es que el grupo 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 grupo que cumpla con los requisitos que se enuncian en este documento.
| |
| − | | |
| − | = Elección del proyecto =
| |
| − | | |
| − | (sec-eleccion)
| |
| − | | |
| − | El grupo debe elegir un proyecto de software para su estudio, análisis, documentación y toma de decisiones. El proyecto de software puede ser de alguno de los siguientes tipos:
| |
| − | | |
| − | * Un proyecto realizado en una asignatura anterior. Por ejemplo el proyecto de IISSI o de Diseño y Pruebas. También podrá ser un proyecto que se esté desarrollando en otra asignatura al mismo tiempo que se desarrolla este trabajo. Puede también ser el proyecto fin de grado. | |
| − | * Un proyecto de software libre al que se tenga acceso en los múltiples repositorios de software libre disponibles. Puede ser un proyecto de gran envergadura o un proyecto pequeño.
| |
| − | | |
| − | Si hay algún otro tipo de proyecto que se quiera tratar (e.g. proyectos desarrollados en una empresa) debe consultar con el coordinador de la asignatura para su aprobación.
| |
| − | | |
| − | Los proyectos elegidos deben cumplir las siguientes características:
| |
| − | | |
| − | * Deben ser proyectos en los que su evolución pueda identificarse fácilmente (e.g. no será bueno elegir proyectos que llevan muchos años sin evolucionar).
| |
| − | * Deben tener un grado suficiente de variabilidad, es decir, serán proyectos que puedan tener distintas plataformas de instalación o distintas configuraciones en general.
| |
| − | | |
| − | El lenguaje de programación, la plataforma de ejecución, el eventual motor de base de datos, las herramientas para la gestión del proyecto que se elijan o cualquier otro aspecto técnico de este tipo no serán relevantes y se da total libertad para elegir el entorno tecnológico que se quiera.
| |
| − | | |
| − | {Entregables}El trabajo elaborado por el grupo 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)”'' <ref>tomado de http://en.wikipedia.org/wiki/Continuous_integration
| |
| − | </ref>
| |
| − | | |
| − | = Documento del proyecto =
| |
| − | | |
| − | El documento del proyecto debe ser un documento que sintetice los aspectos del proyecto elegido con respecto a los temas vistos en clases.
| |
| − | | |
| − | Debe ser un documento técnico y práctico de modo que se eviten párrafos que no sean útiles.
| |
| − | | |
| − | Debe ser un documento presentado de manera profesional guardando la forma en los estilos y contenidos y con el máximo nivel de rigor académico y profesional.
| |
| − | | |
| − | Tendrá (al menos) los siguientes apartados:
| |
| − | | |
| − | * Resumen: tendrá entre 200 y 500 palabras para resumir el proyecto presentado.
| |
| − | * Introducción: se pondrá en contexto el proyecto elegido y los aspectos fundamentales para entender el resto del documento.
| |
| − | * Gestión del código fuente: se explicarán los procesos, técnicas y herramientas para la gestión del código del proyecto. Evite poner información de las herramientas en sí que se pueda encontrar en fuentes bibliográficas o internet. Si es del caso haga referencia a ellas. Céntrese en los aspectos particulares de su proyecto, por ejemplo, ¿cómo se gestionan las ramas en el código? ¿cómo se aplica un parche ('''patch''')? ¿cómo se aprueban los cambios? ¿qué roles existen en la gestión del código?, ¿qué políticas de nombre y estilo se utilizan en el código fuente?.
| |
| − | * Gestión de la construcción: similar al apartado anterior se definirán los procesos que se usan a la hora de construir el proyecto, ¿qué herramientas se usan? ¿cómo se usan? ¿cada cuánto tiempo se realiza una construcción del proyecto?, etcétera.
| |
| − | * Gestión de entregables: ¿qué elementos del proyecto son “entregables”? ¿cómo se generan? ¿cómo se identifican? ¿cómo se gestiona la publicación o entrega? ¿dónde se entrega? ¿qué roles existen en la entrega?
| |
| − | * Gestión del despliegue: ¿qué mecanismos de despliegue se definen? ¿qué procesos? ¿qué plataformas? ¿qué herramientas?
| |
| − | * Gestión de incidencias y depuración: ¿qué mecanismos de depuración se usan? ¿cómo se gestionan los cambios? ¿qué procesos? ¿qué roles? ¿qué estados se manejan? ¿qué políticas para descartar, fomentar o retardar un cambio?
| |
| − | * Gestión de la variabilidad: ¿qué mecanismos se usan? ¿qué mecanismos se podrían usar? ¿en qué niveles se gestiona la variabilidad?
| |
| − | * Integración/despliegue continuos: ¿existen mecanismos de IC y DC? ¿se podrían introducir? ¿cómo?
| |
| − | * Mapa de herramientas: Debe dar un esquema de cómo se conectan las herramientas que se usan en el proyecto, qué relaciones tienen o qué relaciones propondría añadir.
| |
| − | * Conclusiones: Enunciar conclusiones en 2 o 3 párrafos y no más de una página.
| |
| − | | |
| − | En cada uno de los apartados tendrá que añadir el enunciado de al menos un ejercicio para realizar dentro de ese apartado. Por ejemplo, crear una rama sobre el tronco de un proyecto. Al mismo tiempo se enunciará la solución a dicho ejercicio.
| |
| − | | |
| − | Si ha elegido un proyecto de software libre y no encuentra respuesta a alguno de los apartados será responsabilidad del grupo definir políticas, procesos, técnicas o herramientas para el aparatado en cuestión.
| |
| − | | |
| − | Es responsabilidad del grupo ser lo más completo posible en la elaboración del documento. No se trata de “rellenar por rellenar” o cubrir sólo que se comenta en este documento. Piense en el trabajo como un entregable final profesional de modo que se evaluará el documento en su conjunto.
| |
| − | | |
| − | = Máquina virtual =
| |
| − | | |
| − | Se deberá entregar una o varias máquinas virtuales que contengan todos los elementos necesarios para realizar los ejercicios de los apartados anteriores además del proyecto en cuestión y todas sus herramientas.
| |
| − | | |
| − | Para la elaboración de la máquina virtual ser usará la versión libre de VirtualBox.
| |
| − | | |
| − | = Diario del grupo =
| |
| − | | |
| − | (sec-diario)
| |
| − | | |
| − | El grupo debe gestionar un diario del grupo 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 grupo 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.
| |
| − | | |
| − | = Fecha para la entrega =
| |
| − | | |
| − | (sec-deadline-entrega)
| |
| − | | |
| − | Se acordará una fecha de entrega del trabajo entre el la clase y el coordinador de la asignatura.
| |
| − | | |
| − | <references />
| |
