Transcription
Uso de herramientas para la adquisición decompetencias transversales asociadas aldesarrollo y mantenimiento de softwareCarlos López, Raúl Marticorena, Pablo Santos y Jesús M. MaudesÁrea de Lenguajes y Sistemas InformáticosUniversidad de BurgosEscuela Politécnica Superior Edf. C09006 Burgos, España{clopezno, rmartico, psluaces, jmaudes}@ubu.esResumenLas herramientas de control de versiones yplanificación de tareas permiten monitorizar yrecoger información sobre el proceso dedesarrollo software. En este trabajo se presenta lautilización de este tipo de herramientas enasignaturas relacionadas con este campo. La ideano es tanto utilizar las herramientas comocontenido per se de las asignaturas, sino servirsede ellas para fomentar y evaluar la adquisición deciertas competencias transversales relacionadascon esas asignaturas. El presente trabajoselecciona esas competencias, estudia las posiblesherramientas, su ámbito de utilización yconveniencia, y finaliza con el análisis delimpacto de las herramientas en las competenciastransversales seleccionadas a través de encuestasa los alumnos.1.IntroducciónExisten muchas asignaturas de informática que ensus actividades prácticas piden como producto aentregar por el alumno un determinado códigofuente como resultado de la resolución de unproblema.El código fuente tiene una naturalezacambiante a lo largo de su vida debidofundamentalmente a dos cuestiones: por un lado,la incorporación de nuevos requisitos, por otro, elasociado al mantenimiento correctivo ocasionadopor errores y defectos no controlados. Paracontrolar y monitorizar los efectos de estoscambios existen herramientas ampliamenteutilizadas en la industria, como son lasherramientas de control de versiones yplanificación de tareas.En un contexto docente, la naturalezacambiante puede venir determinada por elprofesor, al incluir nuevos requisitos, y por elalumno que va transformando el código hastaalcanzar la solución final. Esta sucesión decambios se hace más palpable si, como eshabitual, la tarea de codificación tiene una vidasuperior a una sesión de prácticas.Cuando un profesor tiene que evaluar uncódigo, generalmente sólo evalúa el productofinal, es decir comprueba propiedades cualitativasde la última versión [13]. En la evaluación no seconsidera la información asociada al proceso dedesarrollo: tiempo empleado en el desarrollo,responsabilidades de los miembros de equipo,versiones de los diferentes estados evolutivos delcódigo, etc.Sin embargo, toda esta información: (i) sueleser relevante desde el punto de vista de laadquisiciónyseguimientodeciertascompetencias transversales en las propiasasignaturas en las que se desarrolla el códigoevaluado, y (ii) puede estar disponible medianteel uso de herramientas de control de versiones yplanificación de tareas.El tipo de competencias transversales que sepretende potenciar y monitorizar con estasherramientas incluyen, por ejemplo, el trabajo enequipo, la planificación, y la capacidad deorganización.Por tanto, parece razonable que laaplicabilidad de las herramientas con este fintome más relevancia en contextos de asignaturasdonde la vida del código sea más larga;entendiendo por vida de código desde que sepropone un enunciado hasta que se entrega (e.g.Trabajos Final de Carrera, Trabajo Fin de Grado oTrabajo Fin de Máster).Sin embargo, parece interesante que losalumnos puedan adquirir las competenciasmencionadas con anterioridad, a fin de quepuedan aplicarlas con mayor naturalidad cuandolleguen a dichas asignaturas de final de carrera,
446por lo que también parece aconsejable que almenos se introduzca la utilización de estasherramientas en asignaturas más básicas, auncuando la vida del código en esas asignaturas seamenor.Esa naturalidad en la utilización de lasherramientas vendrá dada en gran medida por elgrado de conocimiento de las mismas. Por tanto,es conveniente elegir las herramientas de formaque su coste de aprendizaje no suponga hacer undoble esfuerzo, tanto a alumnos, como aprofesores.En lo que sigue el artículo se estructura de lamanera siguiente. En la sección 2 se seleccionanlas competencias transversales a tratar, el procesoseguido para su posible monitorización y unestudio sobre trabajos similares. En la sección 3,se presenta un marco tecnológico de herramientassoftware que permita monitorizar el proceso. Enla sección 4, se presenta el escenario concreto deaprendizaje donde se realiza la experiencia y elplan llevado a cabo. En la sección 5, se analizauna evaluación por parte de los alumnos sobre laobtencióndecompetenciastransversalesmediante la herramienta utilizada. Por último, enla sección 6, se enumeran unas conclusiones ylíneas futuras de actuación.2. Selección de competenciastransversales y su monitorizaciónEl objetivo general es monitorizar el proceso dedesarrollo y mantenimiento de código paracomprobar la adquisición de ciertas competenciastransversales.El tipo de herramientas utilizadas es pues, elque determina qué competencias transversales sonsusceptibles de ser tratadas. Las competenciastransversales elegidas son mostradas en la Tabla 1y toman como referencia las descritas en el RealDecreto 1393/2007 [15] y en el Libro Blanco deIngeniería Informática (LB). Además en la tablase ha añadido una columna para identificar lacompetencia (Id).Para conseguir el objetivo marcado el trabajoha constado de las siguientes etapas:1. Estudio y selección de herramientas quepermitan monitorizar el proceso de desarrolloy mantenimiento de código y su relación concompetencias transversales.Recursos Docentes2. Aprendizaje y uso de herramientas por partede profesores como alumnos en variasasignaturas.3. Evaluación del uso de las herramientas y surelación con competencias transversales porparte de los alumnosDescripciónIdCapacidad de organización y planificaciónC1Conocimientos de informática relativos alámbito de estudioC2Capacidad de gestión de la informaciónC3Trabajo en equipoC4Planificación y gestión del tiempoC5Tabla 1.Competencias transversalesEn la medida de nuestro conocimiento, enotros trabajos como [20], se expone unaexperienciaprácticadeaplicacióndeherramientas de gestión de configuraciones, perosin abordar un estudio como el realizado en elpresente trabajo. Otras experiencias similares encursos de ingeniería del software pueden serconsultadas en [2] y [9], enfocadas a la mejora decompetencia de trabajo en grupo simulando elfuncionamiento real de un proyecto. En esamisma línea en [19] se plantea el uso de estasherramientas para el seguimiento de los alumnosen las asignaturas. En [14] también se apunta laimportancia en el aprendizaje basado enproyectos del uso del control de versiones yherramientas de cooperación en web. Laimportancia de la utilización de este tipo desoluciones es evidente con la inclusión de tallereso workshops para docentes [4]. En nuestro trabajono sólo se pretende incidir en el uso de este tipode herramientas, sino en abordar la adquisición decompetencias transversales a lo largo de suaplicación en diferentes materias y asignaturas.3. Herramientas de monitorización parael desarrollo de códigoDesde un punto de vista docente, el desarrollo decódigo puede verse como la realización de unadeterminada tarea por parte de los alumnos quedebe entregarse en una fecha determinada. Comoconsecuencia, el alumno entrega un resultado
XVI Jornadas de Enseñanza Universitaria de la entos electrónicos.Con un enfoque generalista, una de lasprimeras aproximaciones que se hizo fue utilizarla funcionalidad de monitorización de losentornos de aprendizaje virtual, como Moodle[16]. La funcionalidad de gestión de grupospermite conocer la intervención de cada alumnoen la tarea, y en consecuencia la intervención decada uno en el trabajo. Pero en el contextoplanteado, muchas tareas pueden referirse almismo fichero resultado. Este modelo de trabajono está soportado de manera natural en lasherramientas de enfoque generalista.En un ámbito más orientado al mundoprofesional, la monitorización de la actividad dedesarrollo de código se realiza utilizandoherramientas de control de versiones yherramientas de gestión de tareas. En este sentido,parece interesante incorporar los conocimientosde este tipo de herramientas en los planes deestudio de manera transversal para que puedan serutilizadas en diferentes asignaturas, en particularen las asignaturas de trabajos fin de grado.El uso de ambas herramientas puede hacersede manera conjunta, de manera independiente oincluso se pueden combinar con los gestores decontenidos educativos. Las exigencias deconocimientos y de aprendizaje de las distintasherramientas varían notablemente.En el caso de gestores de tareas, se puedeintroducir desde los primeros cursos de grado, yel tiempo dedicado para que los alumnos puedanutilizarlos de manera básica puede estarcomprendido entre una y dos horas de prácticas.Los gestores de tareas proporcionan una visiónque puede ayudar a abordar la adquisicióncompetencias de capacidad de organización,planificación y gestión del tiempo. Aunque eneste trabajo no se pretende evaluar un conjunto deherramientas de este tipo, cabe destacar que comocriterio de selección se ha considerado el acceso ala herramienta a través de Internet y que seintegre con otras funcionalidades de desarrollo decódigo. Así, la herramienta elegida es el portalXP DEV con su planificador para el seguimientode proyectos [22]. El portal está orientado asoportar la metodología de desarrollo deproyectos eXtreme Programming, [11] donde lasdiferentes tareas del proyecto se agrupan porhistorias y éstas a su vez en iteraciones.447El uso de los sistemas de control de versionesrequiere de unos conocimientos más avanzadospor parte de los alumnos. Además, su aprendizajey uso puede requerir varios estados de madurezadquiridos en diferentes cursos. Este tipo desistemas pueden ayudar a monitorizar laadquisición de competencias como la capacidadde organización y de gestión de la información.La elección del sistema depende de las siguientesrestricciones:x Utilizar la misma herramienta en todas lasasignaturas implicadas.x Uso del sistema mediante aplicaciones de redcliente/servidor.x Disponer de herramientas flexibles quepermitan consultar la utilización de o estas premisas se eligió un sistemacomercial llamado Plastic SCM [5]. La empresadesarrolladora del sistema, Códice Software, haproporcionado gratuitamente una licencia deservidor y soporte de mantenimiento. Respecto ala funcionalidad frente a otros sistemas de códigoabierto, como Subversión [17], se destaca la fácilgestión de ramas, integración con sistemas degestión tareas, personalización de de consultassobre el uso de repositorios y visualizacióngráfica de monitorizaciones.4. Especificación de las experienciasEn este apartado se especifica el conjunto deexperiencias aplicado a contextos concretos deasignaturas. En la Tabla 2 se da una visión globalde las asignaturas implicadas, y de las tareas quesupone para los profesores y alumnos laincorporación de dichas herramientas. Laexperiencia ha sido evaluada en dos titulacionesIngeniería Técnica de Informática de Gestión(ITIG) e Ingeniería Informática (II). La estrategiaseguida en ITIG ha sido utilizar el gestor de tareasdel portal XP DEV en una única asignatura de 3ercurso de la titulación. En el caso de la titulaciónde II, la estrategia se ha basado en utilizar ungestor de control de versiones y su utilización seha distribuido en varias asignaturas.En las siguientes secciones se describe conmás detalle el contexto de enseñanza para facilitarsu comprensión y su posible reproducción enotros ámbitos similares.
448Recursos DocentesProgramación Avanzada, 3º ITIGTareas del profesorTareas del alumnoTPA A1 Desarrollo de un miniTPA1 Presentación delproyecto de programación desdeportal XP-DEV (1 hora).cero. (6 horas en grupos de 4TPA2 Registros de usuarioalumnos).y grupos (1 hora).Planificación y Gestión de Proyectos, 4º IITareas del profesorTareas del alumnoTPGP A1 Operaciones básicasde sistema de SCM (2 horas engrupos de 2 alumnos).TPGP1 Instalación deTPGP A2 Técnica deservidores, uno por cadadesarrollo "main linegrupo de prácticas (2 horas).development" (2 horas en gruposTPGP2 Preparar losde 2 alumnos).guiones de la prácticas conTPGP A3 Técnicas decasos de estudio (4 horas).desarrollo basadas en branching.(4 horas en grupos de 2alumnos).Diseño y Mantenimiento del Software II, 5º IITareas del profesorTareas del alumnoTPDM A1 Desarrollo deTPDM1 Organización deprácticas guiadas en paralelolas prácticas guiadas en elcon el profesor (4 horas enrepositorio central (1 hora).grupos de 2 personas).TPDM2 Desarrollo de dosTPDM A2 Mantenimiento deprácticas guiadas deun código para mejorar sumantenimiento de códigocalidad mediante inspecciones ymediante refactorizacionesreestructuración de diseño. (6(4 horas).horas en grupos de 4 alumnos).Sistemas Informáticos, 5º IITareas del profesorTareas del alumnoTSI1 Seminario de PlasticTSI A1 Desarrollo del trabajoSCM impartido por laempresa Códice Software (4 fin de carrera utilizando elrepositorio para gestionar lashoras).versiones de sus productosTSI2 Creación de unrepositorio por cada petición software.de proyecto.Tabla 2.para recursos y tres ficheros con manuales.Aunque la naturaleza de la práctica incide en lascompetencias transversales es difícil definir suevaluación. El enfoque de evaluación continuaplanteado con las entregas parciales, exigedisponer de mecanismos que ayuden al profesor aevaluar tanta cantidad de información. En estesentido, se obliga al grupo de alumnos a que cadaentrega lleve asociada una planificación de tareas,donde se deben definir y agrupar en historias deusuario. La correcta gestión de tareas de cadagrupo ha supuesto un 10% de la nota final de lapráctica.En la Figura 1 se muestra una monitorizaciónglobal del proceso de prácticas en la últimaentrega. Cada fila recoge los resultados de cadagrupo de prácticas. La información de las celdasrelacionada con las tareas e historias muestra elnúmero total, y entre paréntesis las pendientes porcompletar. De ese modo, se observa que losgrupos G03 y G06 no han terminado suplanificación, y que la agrupación de tareas enhistorias de G03 no parece adecuada puesto quesólo ha definido una historia.Además de esta información se permite:recoger la traza de cada tarea, la definición yorganización, el tiempo estimado, los incrementosde tiempo y qué miembro del equipo realizó latarea.Visión global de la experiencia4.1. Programación AvanzadaEn esta asignatura los alumnos desarrollan unpequeño proyecto de programación desde cero engrupos de cuatro personas. El objetivo es aplicarconceptos de patrones de diseño [8] yprogramación web con bibliotecas de Java. Elcaso de estudio elegido se fundamenta en [12],donde se da una visión del aprendizaje depatrones de diseño en un plan de estudios.La práctica tiene un tiempo establecido deseis horas, distribuidas en tres sesiones, con unaevaluación parcial en cada sesión. Una estimacióndel número de ficheros que puede contener elproducto final sería entorno a diez ficheros paracódigo fuente, dos ficheros de lotes paraautomatizar el proceso de desarrollo, diez ficherosFigura 1. Monitorización global de tareas conXP DEV4.2. Planificación y gestión de proyectosEn esta asignatura se introducey práctica los conceptosconfiguración de softwarefamiliarizaalalumnode manera teóricade gestión de(SCM) [3]. Seconconceptos
XVI Jornadas de Enseñanza Universitaria de la Informáticafundamentales tales como1: versionado deelementos, creación de líneas base (releases,baselines), integraciones (merges), desarrolloparalelo (branching), técnicas de integración da), relación de SCM con testing y con elciclo completo de construcción de software(testing automático, gestión de tareas, controldiario de proyecto), relación de SCM conmétodos ágiles y entrega incremental.El objetivo de las prácticas es familiarizar alalumno con los conceptos de SCM mostrados enteoría. Se busca que el alumno domine lastécnicas básicas de gestión de configuraciónutilizando una herramienta concreta, como PlasticSCM. Las prácticas se organizan en tres sesionesguiadas por el profesor donde cada alumnodispone de una instalación propia del servidor dePlastic SCM.En la primera sesión de dos horas, conceptosbásicos, se practican las operaciones básicas deversionado de elementos: añadir elementos alcontrol de versiones, crear modificaciones yvisualizar diferencias.En la segunda sesión de dos horas, se practicacon técnicas de trabajo “main line development" o"trunk development". Se trata de la técnica mássimple de SCM y se explica al alumno susventajas e importantes carencias. Se trabaja sobreuna única rama con varios espacios de trabajo yse simulan conflictos debidos a cambiosconcurrentes en los mismos archivos. Seintroduce el concepto de "merge" durante elproceso de "checkin". Se explica elfuncionamiento del "merge de tres vías" (threeway-merge) sobre una única rama, explicando elalgoritmo de cálculo de antecesor común desdeuna perspectiva genérica aplicable a variasherramientas.En la tercera sesión de cuatro a seis horas,Branching y merging, se explica el concepto yutilidad del trabajo con ramas y del desarrolloparalelo como paradigma superior a "main linedevelopment". Se explican patrones de branchingcomo "branch per task" y "branch perdeveloper". Se destacan las ventajas de dichospatrones y su impacto en la gestión de proyecto,1Debido a la falta de consenso en la traducción deciertos términos técnicos, los autores han optado pormantenerlos en inglés para no dificultar su comprensión.449estabilidad de versiones, trazabilidad de cambiosy relación con gestión de requisitos. Los alumnostrabajan en varias ramas y realizan cambiosconflictivos en los mismos ficheros forzandointegraciones posteriores. Se explica el conceptode integración controlada, la figura del integradory las ventajas y desventajas respecto a integracióncontinua.4.3. Diseño y mantenimiento del software IIEn esta asignatura se tratan conceptos como lacalidad basada en inspecciones mediante métricasde código [18], e inspecciones de diseño basadaen patrones orientados a objetos [8]. Losresultados de las inspecciones son informes deanomalías que provocan reestructuraciones decódigo. En el caso concreto de esta asignatura serealizan mediante refactorizaciones de código [7].El concepto de refactorización de código esnuevo para los alumnos. Para su explicaciónpráctica se utilizan cuatro sesiones de prácticasguiadas, donde a los alumnos en paralelo con elprofesor, realizan varios casos prácticos derefactorización utilizando el entorno de desarrolloEclipse. El primer caso práctico dura dos sesionesy se fundamenta en el ejemplo guía que sepresenta en [7]. El profesor a modo de entrenadorrealiza previamente las refactorizaciones desde elentorno de desarrollo mostrándolas mediante unproyector. El segundo ejercicio, se basa en elsupuesto práctico disponible en [6]. Comoestrategia docente se disminuye la intervencióndel profesor, que se limita a analizar losproblemasdelsistemayasugerirrefactorizaciones para mejorar su diseño.Ambas prácticas se realizan en grupos de dosalumnos y uno de los problemas que plantea es elseguimiento de las mismas. Para abordar elproblema, se usa la extensión de Eclipse paratrabajar como cliente del sistema Plastic SCM, yse crea en un servidor central, un repositorio paraalmacenar los trabajos de la asignatura y gestionarlas cuentas de usuarios. En cada sesión se crea unconjunto de ramas, una por cada grupo deprácticas. Cada una de las tareas de la sesión esenviada al repositorio de control de versiones. LaFigura 2 muestra de manera gráfica lamonitorización de una sesión. Cada grupo tienesu rama (G1 1 .), y cada cuadrado en la línea devida se corresponde con una operación de entregade documentación al repositorio. Gráficamente se
450Recursos Docentesobserva que el grupo G1 1 puede estar perdidoporque no está realizando entregas.Posteriormente a los alumnos se les proponela realización de una práctica obligatoria donde demanera no guiada identifican y resuelvenanomalías en un sistema existente. Esta prácticadura tres sesiones de dos horas y se realiza engrupos de cuatro personas.5. Evaluación de la experienciaEn las asignaturas expuestas se ha realizado unaserie de encuestas anónimas a los alumnos. Laencuesta está compuesta por un conjunto depreguntas (ver Tabla 3) donde se relaciona laherramienta a evaluar (XP DEV, Plastic SCM)con las competencias transversales denotadas enla segunda columna como Ci, y seleccionadassegún la Tabla 1. Cada pregunta se valoraba de 1a 5 (1 nada, 5 mucho, las respuestas en blancono se valoran).P1. ¿Crees que el uso de la Herramienta puedemejorar la organización y planificación respecto aactividades asociadas al proceso desarrollo desoftware?P2. ¿Crees que el uso de la Herramienta puedemejorar tus conocimientos de informática relativos alproceso configuración de software?P3. ¿Crees que el uso de la Herramienta puedemejorar tu capacidad de gestión de informaciónasociada al proceso desarrollo de software?P4. ¿Crees que el uso de la Herramienta puedemejorar tus conocimientos de planificación y gestióndel tiempo?P5. ¿Crees que el uso de la Herramienta puedeayudarte a trabajar en equipo?P6. ¿Utilizarías la Herramienta en el desarrollo delproyecto fin de carrera?Tabla 3.Figura 2. Monitorización de versiones en unasesión de prácticasC1C2C3C5C4C2Preguntas de la encuesta e identificadorde competenciasLa Tabla 4, Tabla 5 y Tabla 6 muestran losresultados de evaluar las experiencias con losalumnos.4.4. Sistemas Informáticos5.1. Análisis de datos de las encuestasEsta asignatura se corresponde con la asignaturade trabajos final de carrera de II. Se sigue unenfoque clásico donde los tutores plantean unproyecto que el alumno tiene que resolver [13].Es realmente en esta asignatura donde elalumno tiene que poner en práctica muchas de lascompetencias adquiridas y cuando puede hacer unuso de manera libre de las herramientasproporcionadas. En el caso de solicitar utilizar elservidor de versiones a los encargados de lasasignaturas, se habilita un repositorio visibletambién para los docentes de la asignatura. Hastael momento, en este curso, han solicitado lacreación de repositorios tres de trece proyectos encurso.Para cada una de las tres encuestas, cada preguntase ha sometido por separado a un test t de unamuestra (one-sample t-test) con nivel designificación del 5%, con objeto de ver si algunade las encuestas rechaza la “hipótesis nula de quela puntuación media global es 3”. Los casos enlos que se rechaza dicha hipótesis son lossiguientes. La pregunta 6 en la Tabla 5 y Tabla 6es valorada por los alumnos por encima de comocabría esperar. Esto puede deberse a que losalumnos de la asignatura PA son de primer ciclo,y todavía no han realizado un proyecto final decarrera, por lo que les falta la experiencia decuáles son las dificultades que entraña y en lassituaciones en las que estas herramientas sonútiles. Sin embargo, los alumnos de las otras dosasignaturas sí tienen esa visión y lo valoran
XVI Jornadas de Enseñanza Universitaria de la Informáticapositivamente. Además, en la asignatura PGP,existen bastantes preguntas ponderadas porencima de cómo cabría esperar, rechazando lahipótesis nula (P2, P3 y P6). Una posibleinterpretación es que la asignatura PGP no utilizala herramienta tanto a nivel de seguimiento decódigo, como las otras dos asignaturas. Por ello,el alumno puede que tenga una visión másoptimista en lo relativo al coste de su uso integrala lo largo de un desarrollo.Encuestados 13Matriculados 31Puntuación / Tabla 4.Media2,622,692,623,082,853,46Resultados de encuesta PAEncuestados 12Matriculados 20Puntuación / Frecuencia1P1P2P3P4P5P628,3%0%0%0%0%0%Tabla 03,423,674,17Resultados de encuesta PGPEncuestados 10Matriculados 11Puntuación / FrecuenciaP1P2P3P4P5P6Tabla ,003,102,102,504,40Resultados de encuesta DMSII451Las herramientas genéricas de contenidoseducativos deben ser adaptadas a los contextosespecíficos de enseñanza para mejorar laadquisición de competencias transversales. Estacaracterística ha sido considerada en ciertasherramientas como Moodle que permite suextensión de actividades mediante módulos. Enuna última etapa de maduración de la experienciase deberían desarrollar módulos que integrasen lafuncionalidad de las herramientas propuestas conalguna plataforma educativa.En ciertas valoraciones de los alumnos no semanifiesta una relación entre el uso de lasherramientas y la adquisición de competencias. Apesar de ello, es destacable que en todos loscursos encuestados, los alumnos valoran muypositivamente la posible utilización de dichasherramientas en el desarrollo de su futuroproyecto fin de carrera (P6). Es decir, valoranpositivamente la competencia de adquisición deconocimientos de informática relativos al ámbitode estudio.Además de las tareas del profesormencionadas en la Tabla 2, la puesta enfuncionamiento de estos nuevos sistemas llevaasociada una carga extra de trabajo relacionadacon la administración del sistema.Los autores son conscientes que laexperiencia debe ser mejorada y maduradaestableciendo un marco más preciso demonitorización que permita una evaluación máscuantitativa y que incluso forme parte de laevaluación del alumno en una asignatura.Este trabajo entronca con otros trabajos como[10], donde se expone de forma muy detallada unsistema de evaluación basado en competencias, ymás concretamente en [21] con la evaluación decompetencias en los Trabajos Fin de Carrera. Elaplicar dichos sistemas sobre el trabajopresentado se establece como línea de trabajofuturo.6. Conclusiones y líneas futurasAgradecimientosEl trabajo se fundamenta en la necesidad deincorporar mecanismos de control para garantizarla adquisición de competencias transversales porparte de los alumnos. En este sentido, se hapropuesto un enfoque de monitorización delproceso de desarrollo y mantenimiento de códigobasado en herramientas.Este trabajo ha sido realizado por el Grupo deInnovación Docente de la Universidad de BurgosDIGIT. Y ha sido financiado parcialmente por laAgencia para la Calidad del Sistema Universitariode Castilla y León y el Banco Santander. ClaveOrgánica [18M9.M2].
452Recursos DocentesReferencias[1] Agencia Nacional de Evaluación de la Calidady Acreditación, Libro Blanco. Título de gradoen Ingeniería Informática. 2004.[2] Beck, John. Using the CVS versionmanagement system in a software engineeringcourse. J. Comput. Small Coll. 20, no. 6(2005): 57–65.[3] Berczuk, S.P. y B. Appleton, SoftwareConfiguration Management Patterns: PracticalTeamwork, Effective Integration. 2002:Addison Wesley.[4] Cigas, John. An introduction to version controlwith Subversion: tutorial presentation. J.Comput. Small Coll. 25, no. 5 (2010): 213–213.[5] CódiceSoftware. Plastic SCM. Sistema decontrol de versiones. 2009; Disponible en:http://www.codicesoftware.es/.[6] Demeyer, S., S. Ducasse, y O. Nierstrasz,Object-Oriented Reengineering Patterns. 2003,Elsevier Science.[7] Fowler, M., Refactoring: Improving the designof existing code 1999: Addison-Wesley.[8] Gamma, E., et al., Patrones de diseño:elementos de software orientado a objetosreutilizable 2006, Addison Wesley.[9] Glassy, Louis. Using version control to observestudent software development processes. J.Comput. Small Coll. 21, no. 3 (2006): 99–106.[10] Jiménez, F., et al., Un sistema de evaluaciónbasado en competencias: Ejemplo para laasignatura Tecnología de la Programación deltítulo de Grado en Ingeniería Informática por laUniversidad de Murcia, en Actas de las XVJornadas de Enseñanza Universitaria de laInformática (JENUI 2009). 2009, Barcelona. p.193-200.[11] Larman, C., Agile and Iterative Development:A Manager's Guide. 2004: Addison-WesleyProfessional[12] López, C. y Marticorena, R., Inclusión depatrones de diseño en un plan de estudios ía Técnica en Informática, en Losestudios de ingeniería informática en EEEScontexto y realidad en la comunidad autónomade CyL, F.J. García Peñalvo, Editor. . p. 17.López, C., et al., Proceso de Gestión deTrabajos Fin de Carrera, en Actas de las XVJornadas de Enseñanza Universitaria de laInformática. 2009: Barcelona. p. 413-420.Milentijevic, Ivan, Ciric, Vladimir, yVojinovic, Oliver. Version control in projectbased learning. Comput. Educ. 50, no. 4(2008): 1331–1338.Ministerio de Educación y Ciencia, RealDecreto 1393/2007, Gobierno de España, 2007,BOE nº 260.OpenSource. Moodle. Entorno de .org/.OpenSource, Subversion. Software de sistemade control de versiones 2000. Disponible en:http://subversion.apache.org/Piattini Velthuis, M.G., Calidad en eldesarrollo y mantenimiento del software, 2002:Ra-Ma.Reid, Karen L., y Wilson, Gregory V. Learningby doing: introducing version control as a wayto manage student assignments. SIGCSE Bull.37, no. 1 (2005): 272–276.Ruiz-Bertol, F.J. y F.J. Zarazaga-Soria. ElControl de Versiones en el aprendizaje de laIngeniería Informática: Un enfoque práctico,en Actas de las XIII Jornadas de EnseñanzaUniversitaria de Informática. 2007. Teruel.Valderrama, E., et al., La evaluación decompetencias en los Trabajos Fin de Carrera,en Actas de las XV Jornadas de EnseñanzaUniversitaria de la Informática. 2009:Barcelona. p. 405-412.XP-Dev. Subversion Hosting integrated withTrac Hosting & Project Tracking for OpenSource and Proprietary projects. Disponible enhttp://www.xp-dev.c
XVI Jornadas de Enseñanza Universitaria de la Informática 449 fundamentales tales como1: versionado de elementos, creación de líneas base (releases, baselines), integraciones (merges), desarrollo paralelo (branching), técnicas de integración (big bang, integración continua, integración controlada), relación de SCM con testing y con el ciclo completo de construcción de software
