|
|
| (No se muestran 41 ediciones intermedias de 2 usuarios) |
| Línea 1: |
Línea 1: |
| − | * [[Archivo:TrabajoEGC.pdf|Enunciado del trabajo en grupo]]
| + | = Enunciado del trabajo: = |
| | | | |
| | + | Bajar el archivo PDF: [[Archivo:TrabajoEGC.pdf|Enunciado del trabajo en grupo]] |
| | | | |
| − | 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.
| + | = Sobre la primera entrega = |
| | | | |
| − | 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.
| + | * [[Comentarios y notas primera entrega 2014]] |
| − | | + | * [[Comentarios a los grupos 2014]] |
| − | 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í:
| + | * [[Comentarios y notas provisionales 2014]] |
| − | | |
| − | ''“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 />
| |
