Proyecto Docente e Investigador sobre Ingeniería de Software y de los Servicios

PROYECTO DOCENTE E INVESTIGADOR PROGRAMAS DOCENTES ANTONIO RUIZ CORT ´ ES Prueba de acceso al Cuerpo de Catedr´atico de Universidad del ´area de Lenguajes y Sistemas Inform´aticos Universidad de Sevilla 29 de Septiembre de 2016 Publicado en septiembre 2016 por Antonio Ruiz Cort´ es Esta obra est´ a publicada bajo la licencia Creative Commons CC-BY-NC-SA 3.0 PRE ´ AMBULO I Por resoluci´ on de 27 de Julio de 2016, BOE n´ um. 190 de 8 de Agosto de 2016, la Universidad de Sevilla convoc´ o a concurso de acceso, entre otras, la plaza 1/31/16. Dicha plaza pertenece al cuerpo de Catedr´ aticos de Universidad, corresponde al ´ area de Lenguajes y Sistemas Inform´ aticos, est´ a adscrita al departamento hom´ onimo y fija como perfil “Investigaci´ on y Docencia en Ingenier´ ıa de Software y de los Servicios”. El presente documento se ha elaborado para cumplir parcialmente con las instrucciones establecidas en dicha convocatoria en relaci´ on a la documentaci´ on a entregar en el acto de presentaci´ on del concurso, a saber: Breve proyecto en el que figuren sus planteamientos docentes e investigadores, con una extensi´ on m´ axima de 50 p´ aginas de tama˜ no A4 con letra 12 pt. de cuerpo, con espaciado interlineal de 1,5 y m´ argenes de 2,5 cm. Programa de, al menos, una de las asignaturas de formaci´ on b´ asica en los estudios de grado u obligatorias incluidas en el perfil de la plaza. Debe contener: el temario detallado, rese˜ na metodol´ ogica y bibliogr´ afica, sistema y criterios de evaluaci´ on y calificaci´ on. La extensi´ on m´ axima de cada programa ser´ a de 30 p´ aginas de tama˜ no A4 con letra de 12 pt. de cuerpo, con espaciado interlineal de 1,5 y m´ argenes de 2,5 cm. Curr´ ıculum vitae cuyos apartados deber´ an adaptarse a los criterios espec´ ıficos de valoraci´ on para la adjudicaci´ on de la plaza. Este documento contiene un proyecto docente e investigador y el programa de varias asignaturas. El curr´ ıculum se adjunta en un documento separado por tenerse que elaborar a partir de los criterios de evaluaci´ on de la comisi´ on juzgadora de esta plaza, cuya fecha de constituci´ on se desconoce en el momento de elaborar este documento. II ´ INDICE GENERAL III Pre´ambulo I I Proyecto Docente e Investigador XIII 1. Proyecto Docente 1 1.1. Contexto ..................................... 1 1.1.1. Qu´ e se espera del proyecto docente . . . . . . . . . . . . . . . . . 1 1.1.2. Sobre el perfil docente de la plaza . . . . . . . . . . . . . . . . . . 1 1.1.3. Organizaci´ ondeladocencia...................... 2 1.1.4. Estado actual de la docencia . . . . . . . . . . . . . . . . . . . . . . 3 1.1.5. Qu´ e mejorar y c´ omoconseguirlo................... 3 1.2. Reflexiones.................................... 4 1.2.1. Qu´ e es un ingeniero del software . . . . . . . . . . . . . . . . . . . 4 1.2.2. La Inform´ atica es una Ingenier´ ıa ................... 5 1.2.3. La Ingenier´ ıa del Software es una profesi´ on............. 6 1.2.4. Principio de Econom´ ıa de la Ense˜ nanza............... 8 1.2.5. Qu´ e caracter´ ısticas queremos que tenga el MITS . . . . . . . . . . 8 1.3. Algunas propuestas de mejora . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Proyecto de Investigaci´on 13 ´ INDICE GENERAL 2.1. Resumen..................................... 14 2.2. FinalidaddelProyecto ............................. 15 2.3. Antecedentes y estado actual de los conocimientos relacionados . . . . . 16 2.3.1. Antecedentes y resultados previos del grupo . . . . . . . . . . . . 16 2.3.2. Antecedentes y estado de los conocimientos cient´ ıfico-t´ ecnicos . 18 2.4. Hip´ otesis, objetivos generales y pertinencia de la investigaci´ on . . . . . . 22 2.5. Objetivos espec´ ıficos .............................. 24 2.6. Metodolog´ ıa................................... 26 2.7. Plandetrabajo.................................. 30 2.8. Justificaci´ on de contrataci´ ondepersonal................... 40 2.9. Planderiesgos.................................. 40 2.10. Impacto Esperado de los Resultados . . . . . . . . . . . . . . . . . . . . . 41 2.10.1. Impacto cient´ ıfico-t´ ecnico social y/o econ´ omico .......... 41 2.10.2. Plan de difusi´ on e internacionalizaci´ on ............... 42 2.10.3. Transferencia de resultados . . . . . . . . . . . . . . . . . . . . . . 43 Referencias 44 II Programas Docentes 51 3. Programa de “Sistemas Orientados a Servicios” 53 3.1. Consideraciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.2. Objetivos y Competencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.3. Contenidos de la asignatura . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.3.1. Relaci´ on detallada y ordenaci´ on temporal de los contenidos . . . 57 IV ´ INDICE GENERAL 3.3.2. Publicaci´ on del material docente . . . . . . . . . . . . . . . . . . . 57 3.4. Actividades formativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.4.1. ClaseIntegral.............................. 59 3.4.2. Sesiones de Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.4.3. MesasRedondas ............................ 62 3.5. Bibliograf´ ıa e informaci´ onadicional ..................... 63 3.5.1. Biograf´ ıageneral ............................ 63 3.5.2. Biograf´ ıa espec´ ıfica........................... 63 3.5.3. Informaci´ onadicional ......................... 64 3.6. Sistemas y criterios de evaluaci´ on y calificaci´ on............... 64 3.6.1. Sistema de evaluaci´ on ......................... 64 3.6.2. Criterios de calificaci´ on ........................ 65 4. Programa de “Arquitectura e Integraci´on de Sistemas Software” 67 4.1. Consideraciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2. Objetivos y Competencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.3. Contenidos de la asignatura . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.3.1. Programa de teor´ ıa........................... 69 4.3.2. Programa de pr´ acticas......................... 74 4.4. Actividades formativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5. Bibliograf´ ıa e informaci´ onadicional ..................... 75 4.5.1. Informaci´ onadicional ......................... 75 4.6. Sistemas y Criterios de Evaluaci´ on y Calificaci´ on.............. 76 4.6.1. Sistema de evaluaci´ on ......................... 76 V ´ INDICE GENERAL 4.6.2. Criterios de calificaci´ on ........................ 77 4.6.3. Resumen del desarrollo de las competencias de la asignatura . . 77 5. Programa de “Dise˜no y Pruebas” 79 5.1. Consideraciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.2. Objetivos y Competencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.3. Contenidos de la asignatura . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.3.1. Lecci´ on 1: Introducci´ on ........................ 82 5.3.2. Lecci´ on 2: Modelos de Dominio . . . . . . . . . . . . . . . . . . . . 82 5.3.3. Lecci´ on 3: Modelos de Persistencia . . . . . . . . . . . . . . . . . . 83 5.3.4. Lecci´ on 4: Repositorios y Servicios . . . . . . . . . . . . . . . . . . 84 5.3.5. Lecci´ on5:Vistas ............................ 85 5.3.6. Lecci´ on6:Controladores........................ 85 5.3.7. Lecci´ on7:Despliegue ......................... 86 5.3.8. Lecci´ on 8: Lecciones Aprendidas . . . . . . . . . . . . . . . . . . . 86 5.3.9. Lecci´ on 9: Pruebas Funcionales . . . . . . . . . . . . . . . . . . . . 87 5.3.10. Lecci´ on 10: Pruebas de Rendimiento . . . . . . . . . . . . . . . . . 88 5.3.11. Lecci´ on 11: Pruebas de Aceptaci´ on.................. 88 5.3.12. Lecci´ on12:Hackathon......................... 89 5.4. Actividades formativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.5. Bibliograf´ ıa.................................... 91 5.6. Sistemas y Criterios de Evaluaci´ on y Calificaci´ on.............. 92 5.6.1. Sistema de evaluaci´ on ......................... 92 6. Programa de Ingenier´ıa del Software y Pr´actica Profesional 97 VI ´ INDICE GENERAL 6.1. Consideraciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.2. Objetivos y Competencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.3. Contenidos de la asignatura . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.3.1. Fase 1: Calentamiento . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.3.2. Fase 2: Dise˜ nodelProyecto ...................... 100 6.3.3. Fase 3: Desarrollo del Proyecto . . . . . . . . . . . . . . . . . . . . 100 6.3.4. Fase 4: Presentaci´ ondelProyecto................... 101 6.3.5. Fase 5: Desarrollo del Plan de Negocio . . . . . . . . . . . . . . . . 101 6.4. Actividades formativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.5. Sistemas y Criterios de Evaluaci´ on y Calificaci´ on.............. 102 6.5.1. Sistema de evaluaci´ on ......................... 102 6.5.2. Criterios de calificaci´ on ........................ 104 Referencias 105 III Ap´endices 107 A. Asignaturas del perfil de la plaza 109 A.1. Asignaturas de primer ciclo . . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.2. Asignaturas de segundo ciclo . . . . . . . . . . . . . . . . . . . . . . . . . 110 B. Necesidad de un Instituto Universitario en Ingenier´ıa Inform´atica 111 B.1. Contexto ..................................... 112 B.2. Por qu´ eunInstituto............................... 112 VII 1 PROYECTO DOCENTE 1 1.1 CONTEXTO 1.1.1 Qu´e se espera del proyecto docente Las bases de la convocatoria que regula el presente concurso establecen la necesidad de que en el proyecto docente figuren el planteamiento docente del candidato para llevar a cabo la actividad docente asociada al perfil de la plaza. En este contexto debe entenderse necesariamente que el planteamiento debe recoger un conjunto de reflexiones y acciones encaminadas a mejorar la actividad docente que actualmente se realiza sobre las asignaturas del perfil. Adem´ as, tambi´ en debe entenderse que dicho planteamiento debe ser realista, esto es, que pueda llevarse a cabo teniendo en cuenta todos los condicionantes asociados a la plaza tales como el contexto normativo, los recursos disponibles y la organizaci´ on de la docencia en el Departamen- to de Lenguajes y Sistemas Inform´ aticos. Empecemos pues por conocer con m´ as detalle el perfil de la plaza. 1.1.2 Sobre el perfil docente de la plaza Las asignaturas directamente relacionadas con la Ingenier´ ıa del Software y de los Servicios y que est´ an adscritas al Departamento de Lenguajes y Sistemas Inform´ aticos (en adelante LSI) son 12 asignaturas en 3 grados, 7 asignaturas en m´ aster y una l´ ınea de investigaci´ on en el programa de doctorado “Ingenier´ ıa Inform´ atica” en la que por ahora no se imparten asignaturas regladas. La relaci´ on completa est´ a en el anexo §A. Se trata pues de un ´ area que abarca los tres ciclos de ense˜ nanza en los que se organiza la ense˜ nanza universitaria, por lo que nuestro planteamiento debe contemplar asignaturas de car´ acter terminal (las de ´ ultimo curso) y de car´ acter intermedio (cursos CAP´ ITULO 1. PROYECTO DOCENTE inferiores). Tambi´ en debe tenerse en cuenta que el m´ aster en Ingenier´ ıa y Tecnolog´ ıa del Software est´ a orientado a complementar la formaci´ on que reciben los estudiantes del Grado en Ingenier´ ıa Inform´ atica- Ingenier´ ıa del Software (GISW en adelante). En el caso del GISW todas las asignaturas corresponden al M´ odulo “Tecnolog´ ıa Espec´ ıfica sobre Ingenier´ ıa del Software”, sobre cuya orientaci´ on no debieran plantearse dudas: materias tecnol´ ogicas, ni b´ asicas, ni cient´ ıficas (ver secci´ on §1.2.2). Por ´ ultimo, si bien el programa de doctorado a´ un no tiene asignaturas regladas, sigue siendo el tercer ciclo de ense˜ nanza y la realizaci´ on de la tesis una actividad formativa, en la que los doctorandos son investigadores en formaci´ on, tal y como se˜ nala el RD 99/2011 que regula las ense˜ nanzas oficiales de doctorado. Ante esta situaci´ on se hace necesario un planteamiento de ampl´ ıa perspectiva y que intente aprovechar las sinergias de la actividad formativa requerida en los tres niveles. En este sentido, entendemos que un enfoque hol´ ıstico puede ser la mejor aproximaci´ on, esto es, explorar las oportunidades de concebir un planteamiento que aprovecha al m´ aximo las relaciones entre las asignaturas de los tres ciclos. 1.1.3 Organizaci´on de la docencia La docencia en LSI se coordina por Unidades Docentes. Estas unidades son responsables de garantizar que los contenidos de las asignaturas coordinadas se incardinen correctamente en los planes de estudios, evitando solapes entre ellas y lagunas en la formaci´ on del alumnado, y que los profesores asignados sean los m´ as adecuados para cada asignatura. Este ´ ultimo punto, la asignaci´ on de profesores a asignaturas, es especialmente singular de LSI y no nos consta que se haga en otros Departamentos de la Universidad de Sevilla. Nos referimos a que la elaboraci´ on del Plan de Asignaci´ on de Profesorado se lleva a cabo por el criterio de idoneidad y no utilizando el orden de prelaci´ on. Esta pr´ actica se emplea en LSI desde su creaci´ on en 1993 y tiene un impacto importante muy positivo en la calidad de la docencia impartida. Por ´ ultimo, tambi´ en merece destacar que los dos Catedr´ aticos de Universidad adscritos a LSI han liderado hasta la fecha los cambios “profundos” que han sido necesa- 2 1.1. CONTEXTO rio llevar a cabo en varias ocasiones. Dado que el presente concurso es para acceder al cuerpo de Catedr´ atico de Universidad, entendemos que el planteamiento debe ser profundo, o cuando menos intentarlo. 1.1.4 Estado actual de la docencia De acuerdo a los informes del Sistema de Garant´ ıa de Calidad de los tres ciclos, en lo referente a las asignaturas del perfil los indicadores son buenos. Las principales quejas son bastantes razonables y f´ acilmente abordables: solapes en contenidos y heterogeneidad en cuanto a los m´ etodos de ense˜ nanza, evaluaci´ on y “sensaci´ on desigual” de carga de trabajo. Esta ´ ultima queja se recibe sobre algunas asignaturas en las que la metodolog´ ıa docente fuerza a que el estudiante realice el esfuerzo semanal planificado. Como no puede ser de otra manera, el esfuerzo planificado es coherente con la carga crediticia asociada a la asignatura y se distribuye de manera bastante uniforme, tal y como se˜ nalan las buenas pr´ acticas, pero al no ser un esquema seguido de manera mayoritaria en las restantes asignaturas, es f´ acil de entender que el alumno perciba que es necesario un mayor esfuerzo. De hecho, tiene parcialmente raz´ on, pues aunque en horas de esfuerzo no se exige m´ as que en otras asignatura, ciertamente el mantener un esfuerzo semanal uniforme suele ir en contra de la tendencia natural hac´ ıa el esfuerzo del estudiante medio que tenemos en nuestra aulas. 1.1.5 Qu´e mejorar y c´omo conseguirlo Qu´ e mejorar y c´ omo conseguirlo es la cuesti´ on nuclear de todo planteamiento sea docente o investigador, y como hemos dicho anteriormente queremos que nuestro planteamiento consiga una mejora de la actividad docente. Para identificar mejoras que realmente supongan un avance significativo hay que salir de la automplacencia y evitar caer en el “sesgo por inter´ es personal” (self-serving bias); la tendencia natural que como miembros de un grupo nos lleva a pensar que lo hacemos igual o mejor que los dem´ as, y que aquello en lo que no somos tan buenos es porqu´ e el sistema lo impide. 3 CAP´ ITULO 1. PROYECTO DOCENTE Para salir de la autocomplacencia propondremos varias reflexiones encaminadas a revisar nuestra posici´ on sobre algunos postulados impl´ ıcitos y expl´ ıcitos sobre los que descansa la actividad docente del profesor. Estas reflexiones han de ser originales en el sentido de Ortega, esto es, volver al origen de la cuesti´ on y a˜ nadir alguna aportaci´ on. Para evitar caer en el sesgo por inter´ es personal, proponemos la receta de Daniel Kahneman (Thinking, fast and slow), poner en funcionamiento a nuestro Sistema 2, ese que usamos cuando de verdad hay que pensar sobre algo serio en el que va en juego nuestros intereses. En este caso, nuestro inter´ es debe ser reflexionar sin miedo a encontrarnos con la siempre inc´ omoda realidad de que no lo hacemos tan bien como pens´ abamos y que tenemos un amplio margen de mejora. 1.2 REFLEXIONES 1.2.1 Qu´e es un ingeniero del software Las circunstancias que han rodeado a la docencia e investigaci´ on en Ingenier´ ıa de Software desde su nacimiento, y las que a´ un le acompa˜ nan, nos han conducido a una situaci´ on en la que la “identidad profesional” de los ingenieros del software no est´ a a´ un del todo conformada y menos a´ un compartida e interiorizada por los profesores que imparten materias en el ´ area. Conformar esta identidad requiere un esfuerzo considerable y ha de ser necesariamente colectivo. Tal y como se˜ nala Aracil “Si el ingeniero quiere definir su propia identidad profesional (y no que se la den hecha otros) tiene que reflexionar sobre ella .. .es por ello que el ingeniero debe filosofar” [2]. Dado que el profesor Aracil lanzaba esta reflexi´ on para los Ingenieros en general, debemos entender que es m´ as que aplicable para los Ingenieros Inform´ aticos, los ´ ultimos en incorporarnos a la familia de las Ingenier´ ıas. Asumiendo que “filosofar” de manera ser´ ıa esta fuera de nuestro alcance, y que conformar la identidad de los ingenieros del software es un esfuerzo colectivo, nos conformaremos con seguir compartiendo algunas reflexiones que creemos pueden contribuir a este proceso de conformaci´ on de la identidad de los profesionales a los que debemos formar y de paso la nuestra propia. 4 1.2. REFLEXIONES Debe por tanto entenderse que las reflexiones que planteamos a continuaci´ on se lanzan con el ´ animo de explicitar nuestra postura, y que por ello se realizar´ a con un estilo asertivo, que en ning´ un caso debe entenderse como avasallador, absoluto y por supuesto cerrado a las modificaciones. 1.2.2 La Inform´atica es una Ingenier´ıa En la lecci´ on inaugural del curso 2014-2015 de la Universidad de Sevilla [57], el Profesor Toro Bonilla presentaba a la Inform´ atica como “una Ingenier´ ıa joven pero muy necesaria”, y se˜ nalaba como en Espa˜ na, y en bastantes partes del mundo, la Inform´ atica se cre´ o con una visi´ on cient´ ıfica y en un primer momento no tuvo inter´ es por una visi´ on ingenieril. Se cre´ o como una licenciatura y, posteriormente, se convirti´ o en una ingenier´ ıa pero sin cambiar esencialmente el enfoque. Tambi´ en se˜ nalaba que en los ´ ultimos a˜ nos se est´ a produciendo un cambio acelerado en las escuelas de Inform´ atica hacia el enfoque cada vez m´ as ingenieril, y abordaba la siempre controvertida cuesti´ on sobre c´ omo de bien est´ an dise˜ nados los Grados de Ingenier´ ıa Inform´ atica de la Universidad de Sevilla, o al menos si puede ser mejorado su enfoque. La respuesta es que pueden y deben ser mejorados, m´ as adelante retomaremos esta cuesti´ on. En sus reflexiones sobre la identidad del Ingeniero, el Profesor Aracil se˜ nalaba que es muy distinto formar ingenieros que formar cient´ ıficos, pues los primeros buscan la utilidad y los segundos saciar la curiosidad. Tambi´ en se˜ nala que resulta crucial que en las Escuelas de Ingenier´ ıa se fomenten las aptitudes que inclinen hac´ ıa la b´ usqueda de la utilidad. Dado que estamos interesados en formar Ingenieros y estamos totalmente de acuerdo con esta visi´ on de Aracil, resultar´ ıa ´ util disponer de un criterio para determinar en qu´ e grado las actuales asignaturas del perfil fomentan estas aptitudes y en qu´ e medida pueden mejorarse si fuera el caso. Aunque Aracil no se plantea esta cuesti´ on directamente, de sus reflexiones puede extraerse un criterio bastante operativo para determinar al menos si va orientada en la buena direcci´ on: “el hacer debe prevalecer sobre el conocer”, esto es, las asignaturas deben priorizar competencias orientadas a hacer frente a las orientadas a saber. 5 CAP´ ITULO 1. PROYECTO DOCENTE Establecer esta priorizaci´ on no es un criterio com´ unmente aceptado, siendo muchos los profesores que defienden f´ erreamente que debe proporcionarse un variado y abultado saco de fundamentos cient´ ıficos frente al uso de herramientas y tecnolog´ ıas concretas, para que sea en la pr´ actica profesional como egresado donde esos fundamentos te´ oricos resulten ´ utiles al reducir la curva de aprendizaje para cualquier entorno tecnol´ ogico al que se enfrente. Sobre esta aproximaci´ on tambi´ en reflexiona Aracil y la tilda de falacia, nosotros nos referiremos a ella como “la falacia de la caducidad tecnol´ ogica anunciada”: “est´a extendida la falacia de que aprendiendo t´ecnicas concretas se adquiere un conocimien- to ef´ımero y perecedero que a los pocos a˜nos envejecer´a y quedar´a obsoleto. Suelen postular, los que as´ı argumentan, que lo deseable es dar una formaci´on cient´ıfica b´asica s´olida, de conocimientos ampliamente aceptados, que les durar´an toda la vida. Olvidan, los que as´ı piensan, que lo esencial en la formaci´on de un ingeniero no es tanto esa base de conocimiento cient´ıfico, cuyo inter´es como basamento cultural no voy a negar, sino, como record´abamos antes, el haber hecho algo concreto. Cuando el estudiante de ingenier´ıa tiene la sensaci´on de que realmente est´a aprendiendo a ser ingeniero es cuando trabaja en problemas concretos, aunque sea empleando para ello procedimientos que indudablemente pronto carecer´an de inter´es y tendr´a que renovar. Pero lo importante, ´el lo sabe bien, no es el procedimiento -ya aprender´a muchos m´as a lo largo de su vida profesionalsino esa enriquecedora experiencia vital que consiste en concebir la soluci´on a un determinado problema, hacer propuestas para resolverlo, ensayarlas, decidir sobre su idoneidad y ser capaz de articular en una s´ıntesis concreta la resoluci´on del problema que se le hab´ıa propuesto. Es precisamente en este punto donde la formaci´on del ingeniero adquiere sus rasgos m´as caracter´ısticos, que la hacen diferente de otras titulaciones en las que se emplean conceptos y lenguajes an´alogos, pero con los que se pretenden alcanzar otros objetivos”. 1.2.3 La Ingenier´ıa del Software es una profesi´on No tenemos espacio para entrar en discusiones circunstanciales sobre el estado actual de la profesi´ on de Ingeniero Inform´ atico, ni tampoco es determinante para el tema que nos ocupa, as´ ı que admitimos sin m´ as que la Ingenier´ ıa Inform´ atica es una profesi´ on. De las caracter´ ısticas comunes a toda profesi´ on, ocupa nos gustar´ ıa reparar en dos: la responsabilidad y la ´ etica. 6 1.2. REFLEXIONES Tal y como se˜ nala el Profesor Toro, los profesionales forman con sus colegas un colectivo, un colegio profesional, que obtiene, o trata de obtener, el control monopol´ ıstico sobre el ejercicio de la profesi´ on; pero, a cambio, debe hacerse responsables ante la sociedad de los productos que dise˜ nan. Por el contrario, los cient´ ıficos no tienen que ser regulados porque ´ unicamente son responsables ante otros cient´ ıficos. Los ingenieros tienen que ser regulados porque son principalmente responsables ante el p´ ublico, ante los usuarios. Por tanto, debe estar perfectamente definido lo que la sociedad espera de los Ingenieros Inform´ aticos, en consecuencia, lo que puede exigirles. En otras palabras, para la madurez de la profesi´ on debe estar perfectamente definido qui´ en es el responsable de los productos dise˜ nados. Por otra parte, tal y como se recoge el C´ odigo ´ Etico y de Buenas Pr´ acticas Profesionales de SISTEDES (Sociedad de Ingenier´ ıa de Software y Tecnolog´ ıas de Desarrollo de Software), debido a sus funciones en el desarrollo de sistemas de software, los ingenieros de software tienen suficientes oportunidades para causar beneficio o generar da˜ no y para habilitar o influenciar a otros a causar da˜ no o beneficio. Para asegurar, en la medida de lo posible, que sus esfuerzos se utilizar´ an para hacer el bien, los ingenieros de software deben comprometerse a hacer de la ingenier´ ıa del software una profesi´ on ben´ efica y respetada. De acuerdo con tal compromiso, los ingenieros de software deber´ an adherirse al C´ odigo De ´ Etica Y Pr´ actica Profesional de alguna Sociedad de Ingenier´ ıa de Software. Debe destacarse, que en el caso del C´ odigo ´ Etico adoptado por SISTEDES, ´ este no pretende contemplar la totalidad de situaciones o circunstancias con las que los profesionales del desarrollo o de la ingenier´ ıa de software se pueden encontrar, sino establecer unas pautas generales de conducta que les orienten en su forma de actuar durante el desempe˜ no de su actividad profesional. En este sentido, es importante los c´ odigos de conducta van m´ as all´ a de la pura normativa legal, puesto que ayudan a guiar el comportamiento en aquellas situaciones para las que no existe ninguna referencia legal. 7 CAP´ ITULO 1. PROYECTO DOCENTE 1.2.4 Principio de Econom´ıa de la Ense˜nanza Durante la preparaci´ on del concurso de acceso al cuerpo de Titular de Escuela Universitaria, cay´ o en mis manos “La Misi´ on” [40], el ensayo de Ortega sobre la Misi´ on de la Universidad en aquella encrucijada hist´ orica de los a˜ nos 30 del siglo pasado. La vigencia de sus reflexiones me sorprendi´ o enormemente y me vino muy bien cuando con el advenimiento del Plan Bolonia revisit´ e con sentido cr´ ıtico lo que ense˜ naba en mis asignaturas, concretamente en las relativas al Dise˜ no de Software, pues la carga crediticia de la asignatura se ve´ ıa mermada sensiblemente. La reflexi´ on m´ as ´ util fue la que el mismo denomin´ oPrincipio de Econom´ıa de la Ense˜nanza: “s´ olo se debe ense˜ nar lo que se puede aprender”, pues observ´ e que pod´ ıa conseguir que el alumno “aprendiera” pr´ acticamente lo mismo en menos tiempo prestando menos atenci´ on a aquellos contenidos te´ oricos que finalmente no se evaluaban. Los cambios aplicados a la asignatura fueron acertados a tenor de los resultados y de la respuesta recibida por los alumnos. Recientemente, tras leer a Biggs [5] me di cuenta que en aquel momento empec´ e, sin saberlo, a orientarme hac´ ıa “el alineamiento constructivista” y que el “alumno medio” de Ortega, Biggs lo llamaba “Roberto”. Tambi´ en he interiorizado los conceptos de “aprendizaje profundo” y “aprendizaje superficial” y creo sinceramente que la lectura de estos textos ayudar´ ıan a que algunos compa˜ neros profesores reflexionaran sobre la manera de enfocar sus asignaturas. La revisi´ on que, durante la preparaci´ on de este proyecto, he realizado de las asignaturas del perfil me permitir´ ıa establecer una relaci´ on de asignaturas que necesitan ser revisadas para mejorar su grado de alineamiento. 1.2.5 Qu´e caracter´ısticas queremos que tenga el MITS Sobre la docencia en el m´ aster “Ingenier´ ıa y Tecnolog´ ıa del Software” (MITS), hay que partir del hecho que ´ este debe complementar los contenidos impartidos en el GISW ya que debe verse como su evoluci´ on natural. Por tanto, es necesario partir de un an´ alisis de cu´ ales son las capacidades adquiridas por los estudiantes en el actual grado. De forma muy general, podemos decir que el GISW ense˜ na a desarrollar sistemas de informaci´ on con las siguientes caracter´ ısticas (o limitaciones): 8 1.2. REFLEXIONES A medida: Est´ a muy orientado a sistemas de informaci´ on desarrollados a medida, en el sentido de que no se hace ning´ un ´ enfasis (salvo quiz´ a en la asignatura ISPP, Ingenier´ ıa del Software y Pr´ actica Profesional) en los conceptos de dise˜ no de producto. De hecho, todo lo que se ve sobre requisitos y en el proceso de desarrollo software llevan esa direcci´ on de forma impl´ ıcita. M´ ınimo de modelos de negocio: Muy relacionado con el hecho de que el t´ ıtulo se centra de forma impl´ ıcita en desarrollos a medida, no se profundiza (salvo algo en ISPP) en los distintos modelos de negocio que pueden aparecer con el desarrollo de productos y software como servicio propios. No escalables: No se ense˜ nan conceptos relacionados con la escalabilidad en ninguna asignatura. Entiendo escalabilidad como la capacidad de desarrollar sistemas cuya capacidad pueda aumentar sin que se degrade su rendimiento. De hecho, el an´ alisis de rendimiento de aplicaciones es algo que tampoco se cubre. Small data: Muy relacionado con lo anterior, tampoco se ense˜ nan t´ ecnicas ni herramientas adecuadas para gestionar grandes vol´ umenes de datos. Es m´ as, ni siquiera se plantea c´ omo manejar un volumen medio de datos. Conceptos muy b´ asicos de seguridad: La seguridad de aplicaciones no se cubre m´ as all´ a de conceptos muy b´ asicos de autenticaci´ on y ataques sencillos de SQL injection o similares. M´ ınimo soporte operacional: Entendiendo como soporte operacional el disponer de mecanismos que ayuden a la detecci´ on de problemas y el mantenimiento de una aplicaci´ on puesta en producci´ on. Aqu´ ı se incluyen aspectos como monitorizaci´ on (con detecci´ on de incidencias durante ejecuci´ on) y aspectos relativos a despliegues sin afectar al funcionamiento de la aplicaci´ on. Conceptos de dise˜ no b´ asicos: Se ense˜ nan los conceptos de dise˜ no necesario para realizar sistemas de informaci´ on relativamente sencillos, pero no se transmiten conceptos necesarios para desarrollar sistemas m´ as complejos como frameworks, bases de datos, servidores web, etc. Nada de business applications: A diferencia de los alumnos del grado en Tecnolog´ ıas Inform´ aticas, los alumnos de ingenier´ ıa del software no conocen nada de 9 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON 2.3 ANTECEDENTES Y ESTADO ACTUAL DE LOS CONOCIMIENTOS RELACIONADOS 2.3.1 Antecedentes y resultados previos del grupo Desde su participaci´ on en el proyecto WEBMADE (TIC 2003-02737), el grupo solicitante ha trabajado activamente sobre metodolog´ ıas y herramientas para el desarrollo de sistemas WEB. En WEB-FACTORIES (TIN 2006-00472), el grupo orient´ o parte de su investigaci´ on hacia la gesti´ on de la variabilidad en l´ ıneas de productos y la gesti´ on de SLAs. En SETI (TIN 2009-07366) abord´ o el an´ alisis sobre modelos de procesos de negocios y las pruebas de motores de an´ alisis. Por ´ ultimo, el proyecto TAPAS (TIN 2012- 32273) se centr´ o en el desarrollo de tecnolog´ ıas para procesos como servicios (BPaaS). La finalidad de BELI es, por tanto, claramente continuista con respecto a la de TAPAS ya que un BPaaS es un caso particular de servicio H2CS. Por tanto, con respecto a TAPAS, BELI plantea una doble extensi´ on. Generalizar y aplicar a otros ´ ambitos los resultados de TAPAS, y resolver carencias detectadas durante el desarrollo de TAPAS que no han sido a´ un cubiertas tales como el soporte inteligente a la operaci´ on del servicio, la reducci´ on del salto entre el dise˜ no del servicio y su implementaci´ on o considerar a las personas al mismo nivel que los recursos computacionales. Las contribuciones previas del equipo de investigaci´ on con respecto a estas tem´ aticas son Dise˜no de servicios En cuanto a la descripci´ on de aspectos relacionados con el dise˜ no de servicios, hemos caracterizado los servicios altamente configurables y definido un metamodelo inicial [23], incluyendo la definici´ on de necesidades de usuario que incluyan preferencias [20]. Referentes a los SLAs, hemos trabajado extensivamente en lenguajes espec´ ıficos de dominio y an´ alisis de acuerdos [38], y en la descripci´ on y publicaci´ on de acuerdos usando principios Linked Data y extendiendo Linked USDL [22]. Tambi´ en hemos abordado el modelado de SLAs para servicios no computacionales [15,33], apoy´ andonos en trabajos previos de definici´ on de indicadores de rendimiento de procesos (PPIs) [14] y recursos humanos [16]). Finalmente, hemos iniciado una l´ ınea referente al modelado de precios asociados a servicios en la nube [34]. Estos resultados han cristalizado en herramientas usadas en varios contratos de I+D+i: IDEAS, PPINOT y CRISTAL. 16 2.3. ANTECEDENTES Y ESTADO ACTUAL DE LOS CONOCIMIENTOS RELACIONADOS Desarrollo de servicios A nivel conceptual, nuestro grupo ha propuesto t´ ecnicas para el desarrollo de envoltorios para adaptar los servicios y hacerlos sensibles al SLA [44]; desde un punto de vista de desarrollo, nuestro grupo ha sido pionero en la construcci´ on de frameworks software [43,50] que son independientes del dominio y que est´ an disponibles para ser utilizados en desarrollos software de manera directa. Estos frameworks est´ an basados en las t´ ecnicas de an´ alisis y modelado mencionados en el apartado anterior. Pruebas software En el contexto de pruebas hemos propuesto un algoritmo evolutivo para la generaci´ on autom´ atica de casos de prueba computacionalmente duros [51]. Una aplicaci´ on de dicho algoritmo al contexto de ingenier´ ıa inversa ha sido publicado en [32]. En un trabajo reciente [53] hemos aplicado la t´ ecnica de pruebas metam´ orficas para la detecci´ on autom´ atica de 19 errores reales en 7 herramientas de an´ alisis de variabilidad incluyendo razonadores SAT y motores de an´ alisis de modelos de caracter´ ısticas. En otra l´ ınea, hemos propuesto varios criterios automatizados para la priorizaci´ on de casos de prueba en l´ ıneas de productos software [55]. Tambi´ en hemos compartido nuestra experiencia sobre pruebas de un sitio de comercio electr´ onico real [52]. Adem´ as, hemos propuesto el framework Drupal como un excelente objeto de estudio para la evaluaci´ on de t´ ecnicas de prueba en sistemas de alta variabilidad [56]. Operaci´on de servicios Dentro de esta iniciativa, nuestro grupo ha colaborado conjuntamente en trabajos seminales para abordar la armonizaci´ on de la elasticidad con los compromisos individuales, de equipos y de organizaciones [19]. Por otro lado, a nivel de monitorizaci´ on, nuestro grupo ha trabajado en el desarrollo de un mecanismo de explicaci´ on de violaciones de SLAs en tiempo de ejecuci´ on [37]. Finalmente, tambi´ en hemos trabajado en la definici´ on de sistemas de gesti´ on de la conformidad que incluyen la comprobaci´ on del estado de la conformidad en tiempo de ejecuci´ on [7]. Tambi´ en es necesario destacar las 13 herramientas desarrolladas, 9 de las cuales han sido registradas y est´ an siendo utilizadas por un n´ umero significativo de empresas e instituciones. Todas estas herramientas e informaci´ on sobre sus usuarios est´ an disponi- 17 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON bles en http://www.isa.us.es/tools. Todos estos resultados han sido seguidos muy de cerca por las EPOs y otras entidades que se han interesado posteriormente por los mismos. Este inter´ es se ha materializado en numerosos contratos de I+D financiados mayoritariamente por concurrencia competitiva en convocatorias p´ ublicas. Esto nos ha permitido adquirir experiencia en cuanto a transferir y comercializar resultados de investigaci´ on con las EPOS. Se mantienen colaboraciones estables con numerosos grupos de investigaci´ on que se traducen en un constante intercambio de estudiantes y doctorandos, publicaciones conjuntas y proyectos de investigaci´ on conjuntos. Los m´ as relacionados con el presente proyecto son el grupo de Scharham Dustdar en la TU Viena, el de Gordon Fraser en la Univ. De Sheffield, el grupo de Jan Mendling en la WU de Viena, el grupo de Flavia Santoro de la UNIRIO, el grupo de Minseok Song de la UNIST y el grupo de Van der Aalst de la TU/Eindhoven. Una relaci´ on completa se puede encontrar en http: //www.isa.us.es. Estas y otras contribuciones cient´ ıficas nos han llevado a obtener cierto reconocimiento por parte de la comunidad cient´ ıfica. A nivel global, y s´ olo en los ´ ultimos 5 a˜ nos, el IP del grupo ha recibido seg´ un Google Scholar m´ as de 3200 citas. 2.3.2 Antecedentes y estado de los conocimientos cient´ıfico-t´ecnicos A continuaci´ on se describen los antecedentes y estado actual de los conocimientos cient´ ıfico-t´ ecnicos de cada una de las l´ ıneas sobre las que se desarrollar´ a el proyecto. Dise˜no de servicios H2CS Para dise˜ nar servicios en general, y H2CS en particular, se necesitan metodolog´ ıas y modelos para describir pormenorizadamente las capacidades de dichos servicios, especialmente cuando se pretende aumentar el grado de automatizaci´ on de las tareas del ciclo de vida de dichos servicios. El estado del arte a este respecto presenta distintos trabajos para la descripci´ on de servicios configurables [29] y enfocados a procesos [62], aunque en general el concepto de servicio altamente configurable ha sido tradicionalmente definido ´ unicamente de manera intuitiva, presentando tambi´ en limitaciones en cuanto a la expresividad de la 18 2.3. ANTECEDENTES Y ESTADO ACTUAL DE LOS CONOCIMIENTOS RELACIONADOS variabilidad y la relaci´ on con servicios no computacionales. En cuanto a SLAs, existen distintas propuestas enfocadas a servicios Web tradicionales [1] y en el ´ ambito de la nube [59] que no soportan la descripci´ on de otros aspectos relacionados con el negocio. Espec´ ıficamente, el modelo de precios asociados a los servicios no est´ a suficientemente cubierto, con algunas propuestas existentes que no tratan la variabilidad de los procesos de compra o descuentos [28]. Finalmente, es necesario poder crear modelos que sean capaces de representar y analizar la evoluci´ on del servicio y sus procesos [46] y de manera entendible por los expertos de negocio [47]. Sin embargo, las propuestas actuales no diferencian entre la organizaci´ on estructural y la organizaci´ on de interacci´ on, lo que hace inviable el modelado del funcionamiento de manera independiente a la organizaci´ on concreta en la que se describe. Frente a estas propuestas se precisan modelos avanzados que den un marco formal de soporte para las caracter´ ısticas avanzadas de los servicios H2CS, incluyendo entre otros aspectos referentes a la alta variabilidad de configuraciones, descripci´ on de necesidades y preferencias de usuario, modelos de precios y provisi´ on de servicios, y en general aspectos m´ as cercanos al proceso de negocio y al factor humano como parte integral de los H2CS. Desarrollo de servicios H2CS El soporte a la construcci´ on de servicios computacionales ha sido abordado de manera extensa por la academia. Desde el punto de vista de la industria, la mayor´ ıa de tecnolog´ ıas de desarrollo actuales proporcionan un modelo semi-automatizado de construcci´ on de servicios a partir de modelos de informaci´ on que pueden ser evolucionados y extendidos de manera controlada [10,12]. Por otro lado, la gesti´ on de la variabilidad y de los SLAs se realiza fundamentalmente de forma ad-hoc sin soporte del ecosistema tecnol´ ogico. Desde el punto de vista de la academia, desde la aparici´ on del paradigma de la computaci´ on en la nube, existen un amplio conjunto de propuestas que proporcionan t´ ecnicas [13,30] y frameworks abstractos [9,11] pero estas propuestas no proporcionan frameworks software para incorporar las t´ ecnicas de manera desacoplada dentro de la construcci´ on de los servicios. Finalmente, en el ´ ambito de servicios basados en humanos, aunque hay algunas propuestas centradas en ofrecer interfaces RESTful a partir de sistemas de gesti´ on de procesos de negocio [45], no exis- 19 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON te ning´ un acercamiento que tenga en cuenta el SLA como un elemento de primer nivel en ´ el mismo [15]. Pruebas automatizadas de servicios H2CS Automatizar las pruebas funcionales y de rendimiento resulta clave para agilizar la validaci´ on y el mantenimiento de los sistemas software a lo largo del tiempo. Algunas de las t´ ecnicas m´ as empleadas para la automatizaci´ on son las pruebas de mutaci´ on [27], pruebas basadas en modelos [60], las pruebas basadas en b´ usqueda [24] o las pruebas metam´ orficas [31]. Sin embargo, aunque estas t´ ecnicas cuentan con un amplio estado del arte, su aplicaci´ on a dominios altamente configurables, donde las distintas variantes del software incrementan exponencialmente el n´ umero de pruebas, y servicios en la nube est´ a a´ un por explorar. En concreto, identificamos los siguientes retos: Aunque servicios RESTful se han convertido en el est´ andar de-facto para la implementaci´ on de servicios en la nube y de arquitecturas basadas en microservicios, las t´ ecnicas de pruebas en servicios web se han centrado fundamentalmente en los servicios web SOAP [3,4,39,54], dejando a los servicios RESTful en un lugar secundario [8]. As´ ı, el desarrollo de t´ ecnicas y herramientas para la detecci´ on de errores, tanto funcionales como no funcionales, en servicios RESTful suponen un reto de investigaci´ on. La violaci´ on de algunos de los t´ erminos de un SLA puede conllevar penalizaciones hacia el proveedor del mismo. Esto hace necesario verificar que ´ este ofrece el comportamiento esperado [41]. En este ´ ambito, se han hecho avances significativos con la aplicaci´ on de t´ ecnicas combinatorias [42] y pruebas basadas en b´ usqueda [17]. Sin embargo, la aplicaci´ on de estas y otras t´ ecnicas en el contexto de H2CS, donde las personas pueden formar parte de los servicios, est´ a a´ un por explorar. La priorizaci´ on de casos de prueba es una t´ ecnica ampliamente utilizada para acelerar la detecci´ on de fallos [49] y resulta especialmente ´ util su aplicaci´ on a sistemas con gran variabilidad. Sin embargo, identificar la combinaci´ on adecuada de criterios de priorizaci´ on que permitan detectar los errores lo antes posible es 20 2.3. ANTECEDENTES Y ESTADO ACTUAL DE LOS CONOCIMIENTOS RELACIONADOS algo que depende del domino de aplicaci´ on y que a´ un no ha sido explorado en profundidad el contexto de los servicios ofrecidos en la nube altamente configurables. Operaci´on de servicios H2CS Proporcionar una gesti´ on automatizada de la operaci´ on de servicios H2CS involucra distintos retos independientes pero relacionados entre si: La operaci´ on del servicio debe estar guiada por la informaci´ on generada por el sistema en forma de eventos. En este sentido, un primer reto es ser capaz de procesar es la generaci´ on de monitores para el sistema. Hay propuestas basadas en el uso de Complex Event Processing (CEP) [6], pero est´ an limitadas a arquitecturas SOA y asume que todos los eventos est´ an en el mismo nivel de abstracci´ on. M´ as completa en ese sentido es [25]. Sin embargo, en ella las consultas CEP se hacen a mano, lo que es propenso a errores y no robusto frente a cambios en el formato de los eventos por lo que ser´ ıa deseable una herramienta que asistiese al desarrollador en esa l´ ınea. Otro reto es la realizaci´ on de predicciones en base a los datos proporcionados por los eventos. Hay una gran variedad de propuestas en esta l´ ınea basadas en el uso de algoritmos de aprendizaje autom´ atico o en m´ etodos estad´ ısticos [35,48]. Sin embargo estos m´ etodos no tienen en cuenta la posible influencia de factores externos en las predicciones as´ ı como el hecho de que la forma en que se ejecuta el servicio puede variar en funci´ on de la hora del d´ ıa o de la ´ epoca del a˜ no. Por ´ ultimo, la gesti´ on de la elasticidad ha sido uno de los aspectos m´ as tratados en la literatura. Una de las propuestas m´ as relevantes es la del grupo del profesor S. Dustdar que est´ a compuesta de un conjunto de t´ ecnicas y herramientas enmarcadas dentro del framework VieCom; en particular este grupo ha sido pionero en la creaci´ on de gestores de elasticidad tanto para servicios computacionales [36,58] como para la incorporaci´ on de equipos humanos dentro del servicio, proponiendo el concepto de Social Compute Unit (SCU) [18]. Desde el punto de vista de plataforma, en los ´ ultimos a˜ nos ha habido distintos proyectos europeos 21 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON como SLA@SOI o Cellar que han abordado esta problem´ atica, sin embargo estos proyectos est´ an fuertemente orientados a la construcci´ on de IaaS y proponen modelos de acuerdos fuertemente orientados a operaci´ on de servicios computacionales sin incorporar modelos de negocio, la intervenci´ on humana como parte de la provisi´ on del servicio, o la gesti´ on de la variabilidad. As´ ı mismo, los frameworks propuestos en estos proyectos est´ an fundamentados sobre arquitecturas pesadas sin incorporar una filosof´ ıa de micro-servicios. 2.4 HIP ´ OTESIS,OBJETIVOS GENERALES Y PERTINENCIA DE LA INVESTIGACI ´ ON La hip´ otesis de partida del proyecto puede formularse como sigue: Hip´otesis El desarrollo de nuevos modelos, t´ecnicas y herramientas para el dise˜no, desarrollo, pruebas y operaci´on de servicios H2CS (h´ıbridos, configurables y regulados por SLAs) puede permitir una mejora en la agilidad para responder a cambios en el negocio y una optimizaci´on de su coste. Por consiguiente, el objetivo general del proyecto BELI es analizar los retos y oportunidades que los servicios H2CS plantean para la gesti´ on de su ciclo de vida, incluyendo su dise˜ no, desarrollo, prueba y operaci´ on, y proporcionar un conjunto de modelos, t´ ecnicas y herramientas que permitan explotar al m´ aximo estas caracter´ ısticas con el fin de agilizar la respuesta a cambios en el negocio y optimizar su coste. Este objetivo se enmarca en el Reto en Econom´ ıa y Sociedad Digital (s´ eptimo re- to identificado en la Estrategia Espa˜ nola de Ciencia y Tecnolog´ ıa y de Innovaci´ on), fundamentalmente en el ´ ambito de Internet del Futuro y del desarrollo, innovaci´ on y adopci´ on de soluciones y tecnolog´ ıas ligadas a cloud computing. 22 2.4. HIP ´ OTESIS, OBJETIVOS GENERALES Y PERTINENCIA DE LA INVESTIGACI ´ ON Estamos convencidos de que ese objetivo permitir´ a disminuir tanto el time-to-market como el tiempo de adaptaci´ on de un servicio con estas caracter´ ısticas a cambios en su competencia. Controlar estos dos factores resulta clave para poder competir en un entorno tan din´ amico y competitivo como es el de los servicios ofrecidos a trav´ es de la nube. Por tanto creemos aportar nuestro granito de arena para que el sector TIC en general y el dedicado a ofrecer servicios a trav´ es de la nube en particular sea m´ as competitiva. Trat´ andose de servicios en la nube, de manera natural el alcance de este impacto tiene ´ ambito global. En ese sentido, la transferencia prevista con la empresa Icinetic con sede en Sevilla pero parte de su negocio en EEUU, para extender hivecell.io con capacidades de gesti´ on de ANS; las previsiones para que nuestra t´ ecnica para priorizar casos de prueba en Drupal se convierta en el nuevo est´ andar de facto de dicha comunidad; y el compromiso por parte de Cupenya para difundir resultados de BELI, determinan el impacto internacional esperado de nuestros resultados. Los contratos de I+D previstos con Everis, Accenture, Isotrol e Isoin empresas que ofrecen soluciones y tecnolog´ ıas ligadas al cloud computing para el ´ area de Salud, Energ´ ıa y Log´ ıstica, determinan el impacto nacional. Finalmente, el que la tecnolog´ ıa desarrollada en BELI resulte de inter´ es para el Servicio Andaluz de Salud, nos permite aventurar que podr´ a ser de utilidad en otras ´ areas de la AAPP siendo su principal impacto el reducir la dependencia de tecnolog´ ıa extranjera y promocionar el desarrollo de tecnolog´ ıa nacional. Asimismo los retos cient´ ıfico-t´ ecnicos est´ an altamente alineados con los retos identificados en la estrategia de I+D+i Horizonte 2020, en cuyos programas de trabajo bianuales (tanto en el WP 2014-15 en su llamada ICT-7, como en el 2016-17, actualmente en fase de borrador) se refleja la importancia de los servicios en la nube y de su configuraci´ on din´ amica, teniendo en cuenta aspectos de calidad y an´ alisis autom´ atico, entre otras cuestiones. Por ´ ultimo, la gran cantidad de grupos de investigaci´ on cuyas l´ ıneas est´ an relacionadas con los retos cient´ ıfico-t´ ecnicos del proyecto (ver secci´ on ??) ponen de manifies- to el elevado inter´ es de la comunidad cient´ ıfica hacia ellos. Adicionalmente, un valor a˜ nadido del proyecto es que los objetivos del proyecto se han definido buscando que 23 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON tengan un car´ acter fundamental, esto es, si se alcanzan, la aplicaci´ on de sus resultados trascender´ a los l´ ımites de esta propuesta. Por ejemplo, t´ ecnicas desarrolladas para la automatizaci´ on de pruebas o el uso de predicciones para facilitar la toma de decisiones basada en datos resultan de utilidad en contextos distintos a los H2CS. En este sentido, por las caracter´ ısticas de los H2CS, el proyecto tambi´ en aborda de forma secundaria el Reto en Salud, Cambio Demogr´ afico y Bienestar. En concreto, en relaci´ on al uso y difusi´ on de las Tecnolog´ ıas de la Informaci´ on como eje vertebrador de un espacio global de e-health para el desarrollo de actividades de investigaci´ on en el ´ area de Epidemiolog´ ıa, Salud P´ ublica y Servicios de Salud as´ ı como en el ´ ambito de la organizaci´ on y gesti´ on del Sistema Nacional de Sanidad. Una prueba de ello es el inter´ es mostrado por dos EPOs (el Servicio Andaluz de Salud y Everis) para la aplicaci´ on de sus resultados a entornos de estas caracter´ ısticas. En concreto se han planteado aplicar para una Plataforma de Investigaci´ on Cl´ ınica (utilidades de validaci´ on estad´ ıstica y resultados de experimentos) y para una Plataforma Inteligente para Unidades de Cuidados Intensivos (medios de predicci´ on y simulaci´ on de procesos para el soporte a la decisi´ on cl´ ınica). 2.5 OBJETIVOS ESPEC´ IFICOS El objetivo general de BELI se puede descomponer en los siguientes objetivos espec´ ıficos: OBJ1: Definir y analizar modelos para dise˜nar H2CS. Los aspectos m´ as novedosos ser´ an: la definici´ on de SLAs complejos tanto para servicios computacionales como no computacionales; la definici´ on de un modelo de precios muy expresivo capaz de definir relaciones entre distintos servicios; y la definici´ on de un modelo de variabilidad que permita modelar procesos altamente configurables. Adem´ as, tambi´ en se abordar´ a el dise˜ no de un cat´ alogo de operaciones de an´ alisis sobre los mismos para extraer informaci´ on relevante de ellos. OBJ2: Desarrollar un framework que reduzca el salto entre el dise˜no del servicio y su implementaci´on. Los aspectos m´ as novedosos ser´ an: la integraci´ on de modelos de SLA, de variabilidad y de precios como artefactos del framework para automa- 24 2.5. OBJETIVOS ESPEC´ IFICOS tizar las tareas relacionadas con ellos; y la inclusi´ on de soporte tanto a servicios computacionales como a servicios basados en personas. OBJ3: Desarrollar t´ecnicas para automatizar las pruebas de servicios H2CS y de la tecnolog´ıa desarrollada en el proyecto. Los aspectos m´ as novedosos ser´ an: el uso de t´ ecnicas de priorizaci´ on de casos de prueba para seleccionar aquellas pruebas m´ as relevantes en servicios altamente configurables, el desarrollo de t´ ecnicas basadas en estudios emp´ ıricos para evaluar el funcionamiento de servicios basados en personas y el uso de t´ ecnicas para automatizar la generaci´ on de casos de prueba. OBJ4: Desarrollar t´ecnicas para automatizar o guiar las decisiones durante la operaci´on del servicio para optimizar costes. Los aspectos m´ as novedosos ser´ an: el desarrollo de t´ ecnicas para dotar de elasticidad en servicios h´ ıbridos teniendo en cuenta el margen de beneficios deseado y nivel de riesgo derivados de sus SLAs, la automatizaci´ on de la elecci´ on de la infraestructura ´ optima donde desplegar y operar el servicio, el desarrollo de mecanismos de monitorizaci´ on instanciados de forma autom´ atica en base al SLA del servicio y el uso de t´ ecnicas de predicci´ on para dar soporte a una toma de decisiones basadas en datos en tiempo real. OBJ5: Considerar a las personas como un elemento de primer nivel del servicio. Los aspectos m´ as novedosos ser´ an: el desarrollo de modelos, frameworks y t´ ecnicas de automatizaci´ on de pruebas y de toma de decisiones basadas en datos que permitan integrar de forma natural personas y software para la realizaci´ on de un servicio. En el proyecto consideramos objetivo como transversal a todos los anteriores y, por lo tanto, es considerado en cada uno de ellos. OBJ6: Aplicar los resultados de los objetivos anteriores a casos de uso concretos. Los aspectos m´ as novedosos ser´ an la puesta en valor de las tecnolog´ ıas innovadoras desarrolladas como resultados de los objetivos anteriores. Este objetivo se realiza a su vez en dos ´ ambitos: (1) puesta en pr´ actica los resultados en al menos 2 H2CS reales desarrollados, usados y operados por el propio grupo de investigaci´ on; (2) y aplicaci´ on de los resultados en casos de uso espec´ ıficos propuestos por las propias EPOs. 25 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON grupo, se analizar´ a la cobertura de estos modelos en cuanto a aspectos relacionados con el nivel de servicio esperado, acuerdos e interacci´ on entre personas y servicios computacionales en la nube dentro de procesos de negocio. En cuanto al modelado del precio, a partir de un estudio inicial [34] se identificar´ an los modelos y extensiones necesarias para describir planes de precios asociados a H2CS y SLAs, as´ ı como el propio proceso de compra, de forma que se ofrezca a las personas involucradas en el ciclo de vida operaciones de simulaci´ on y optimizaci´ on de utilizaci´ on y pagos en la operativa de servicios H2CS. Finalmente, bas´ andose en trabajos previos relativos a la separaci´ on entre organizaci´ on estructural y organizaci´ on de interacci´ on, se definir´ an t´ ecnicas de modelado y metodol´ ogicas para soportar la evoluci´ on de servicios H2CS y sus distintas alternativas de despliegue. Todos estos modelos ser´ an integrados en la herramienta de dise˜ no IDEAS desarrollada por el grupo, extendiendo su actual funcionalidad para ofrecer operaciones de an´ alisis que faciliten el salto entre el dise˜ no y el desarrollo de H2CS. Dicha herramienta dar´ a asimismo soporte al dise˜ no colaborativo de H2CS, facilitando el control de versiones y la publicaci´ on de descripciones en la nube manteniendo los principios de Linked Data. Tareas: Tarea 1.1. Modelado y an´ alisis de la variabilidad en H2CS para soportar la personalizaci´ on y configuraci´ on de servicios. Tarea 1.2. Modelado y an´ alisis de SLAs para provisi´ on de servicios H2CS en la nube. Tarea 1.3. Modelado y an´ alisis de planes de precios y procesos de compra de H2CS. Tarea 1.4. Desarrollo de metodolog´ ıas y t´ ecnicas de modelado para representar y dise˜ nar la evoluci´ on de servicios H2CS. Tarea 1.5. Desarrollo de una herramienta colaborativa multi-modelo para el dise˜ no integrado de H2CS. 32 2.7. PLAN DE TRABAJO Justificaci´on de contrataci´on de personal: Para las tareas relacionadas con el desarrollo de herramientas y la implementaci´ on de las operaciones de an´ alisis se har´ a necesaria la contrataci´ on de personal t´ ecnico de apoyo. Se estima que para la correcta ejecuci´ on de este paquete de trabajo se necesitar´ a una persona contratada con titulaci´ on de Grado en Ingenier´ ıa Inform´ atica o equivalente. Paquete de trabajo 2: Desarrollo de servicios H2CS Objetivos: Los asociados al OBJ2 y parcialmente al OBJ5. Contribuciones principales: Se desarrollar´ a un framework que permita al servicio una adaptaci´ on ´ agil a cambios en el negocio por medio de las siguientes caracter´ ısticas: (1) incorporar de forma expl´ ıcita los modelos construidos en el PT1 como una forma de desacoplar su evoluci´ on de la evoluci´ on de los ´ ambitos funcionales; (2) dise˜ nar una arquitectura de micro-servicios RESTful que permita el uso de mecanismos no intrusivos para regular el comportamiento y coordinaci´ on de cada microservicio a trav´ es de los SLAs y los modelos de configuraci´ on que definen la variabilidad, y (3) integrar sistemas flexibles de soporte a la coordinaci´ on de personas dentro de la arquitectura anterior. Descripci´on: En los ´ ultimos a˜ nos, el grupo ha sido pionero en la construcci´ on de bibliotecas que permiten la creaci´ on y el an´ alisis de modelos de SLAs y variabilidad a trav´ es de las herramientas ADA y FAMA, respectivamente. En base a estos trabajos y a los resultados del PT1, este PT abordar´ a las siguientes acciones. Se desarrollar´ an componentes independientes de dominio para facilitar el uso por parte del sistema software de los artefactos modelados en dise˜ no. En base a estos componentes, se dise˜ nar´ an mecanismos no intrusivos para regular y coordinar los distintos micro-servicios: a nivel de front-end permitiendo que los distintos componentes de la interfaz gr´ afica de usuario (GUI) reaccionen y se adapten siguiendo el estado del SLA de cada usuario, y a nivel de back-end, proporcionando un envoltorio a los micro-servicios RESTful que adapte su comportamiento en base a los SLAs. Finalmente, se aplicar´ a la misma filosof´ ıa para regular sistemas flexibles de soporte a la coordinaci´ on de personas (plataformas web como Trello o el correo electr´ onico); en particular, se dar´ a especial ´ enfasis a la 33 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON integraci´ on de motores de proceso fundamentada en las t´ ecnicas y herramientas desarrolladas en el grupo para el modelado y c´ alculo de indicadores de procesos (PPIs). Esto permitir´ a integrar las actuaciones desarrolladas, a nivel del equipo humano dentro de la arquitectura de micro-servicios, permitiendo la construcci´ on de H2CS y la operaci´ on automatizada propuesta en el PT4. Tareas: Tarea 2.1. Dise˜ no de componentes independientes de dominio para los artefactos de dise˜ no del H2CS. Tarea 2.2. Desarrollo de mecanismos para la adaptaci´ on din´ amica de la GUI. Tarea 2.3. Desarrollo de envoltorios de micro-servicios para adaptar su comportamiento. Tarea 2.4. Desarrollo de mecanismos de regulaci´ on e integraci´ on para sistemas flexibles de soporte a la coordinaci´ on de personas. Justificaci´on de contrataci´on de personal: Para poder abordar este paquete de trabajo con ´ exito es necesario disponer de un ingeniero con conocimientos amplios acerca de servicios RESTful, arquitecturas de micro-servicios y motores de proceso. Paquete de trabajo 3: Pruebas de servicios H2CS Objetivos: Los asociados al OBJ3 y parcialmente al OBJ5. Contribuciones principales: Se desarrollar´ an t´ ecnicas autom´ aticas de generaci´ on de casos de prueba para la detecci´ on de errores, funcionales y no funcionales, en los H2CS. Cuando la automatizaci´ on total no sea posible (ej. debido al problema del or´ aculo), se trabajar´ a en el dise˜ no de algoritmos y criterios de priorizaci´ on de casos de prueba que permitan acelerar la detecci´ on de fallos. Descripci´on: En el proyecto se explorar´ a el uso de pruebas metam´ orficas para la automatizaci´ on de pruebas en servicios web RESTful, como tecnolog´ ıa clave para la 34 2.7. PLAN DE TRABAJO implementaci´ on de H2CS. Se har´ a especial hincapi´ e en validar la conformidad con los SLA que regulan el servicio. Por otra parte, se desarrollar´ an t´ ecnicas basadas en b´ usqueda para la detecci´ on de errores no funcionales en los H2CS. Finalmente, se abordar´ a el dise˜ no de criterios y algoritmos de priorizaci´ on de casos de prueba (mono y multi-objetivo) para la detecci´ on temprana de errores en H2CS y en el resto de herramientas derivadas del proyecto. Los resultados anteriores ser´ an evaluados en varios escenarios, mediante el uso de t´ ecnicas de mutaci´ on o hist´ orico de fallos, que permitan evaluar su efectividad. Tareas: Tarea 3.1: Estudio del arte de la aplicaci´ on de pruebas metam´ orficas en el ´ ambito de servicios y aplicaciones web. Tarea 3.2: Desarrollo de t´ ecnicas y herramientas para la generaci´ on autom´ atica de casos de prueba en servicios web RESTful, preferiblemente regulados por SLA. Tarea 3.3: Desarrollo de algoritmos multi-objetivo de priorizaci´ on de casos de prueba y aplicaci´ on en el contexto de los H2C2S. Tarea 3.4: Desarrollo de t´ ecnicas basadas en b´ usqueda para la generaci´ on de pruebas no funcionales en el contexto de los H2C2S. Justificaci´on de contrataci´on de personal: Para poder abordar este paquete de trabajo con ´ exito es necesario disponer de un ingeniero con conocimientos amplios acerca de servicios RESTful, pruebas y metaheur´ ısticas. Paquete de trabajo 4: Operaci´on de servicios H2CS Objetivos: Los asociados al OBJ4 y parcialmente al OBJ5. Contribuciones principales: Se crear´ a una plataforma de gobierno que dotar´ a a los H2CS de varios componentes para automatizar o guiar las decisiones durante la operaci´ on del servicio, aline´ andola con los objetivos de negocio y optimizando costes. En 35 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON concreto: (1) un componente de gesti´ on de los acuerdos de la organizaci´ on (tanto externos con los clientes como internos por parte de los equipos); (2) un componente de soporte al negocio que permita gestionar de forma automatizada una pol´ ıtica de precios y SLAs ofrecidos a los clientes que este alineada con los costes de infraestructura y de operaci´ on, y (3) un componente de gesti´ on de la elasticidad que permita el escalado inteligente de los subsistemas que componen el H2CS para alcanzar los objetivos de negocio. Descripci´on: Este paquete de trabajo se apoyar´ a en el uso del framework propuesto en el PT2 y los artefactos de modelado del PT1. En particular, se abordar´ a la construcci´ on de una plataforma que de soporte al despliegue y operaci´ on automatizado de H2CS estructurada en una arquitectura de micro-sevicios con tres componentes principales: Un componente de gesti´ on de acuerdos que permita mantener el estado del acuerdo a trav´ es de su consulta y modificaci´ on por parte de todos los componentes del H2CS. Desde el punto de vista externo, el componente deber´ ıa proporcionar un portal de auto-provisionamiento y gesti´ on a los clientes del H2CS para ver el estado actual de su SLA en base al uso que han hecho del servicio y plantear nuevas compras; en este contexto, se abordar´ a el estudio de t´ ecnicas para la generaci´ on automatizada de monitores en base a los SLAs adquiridos con los clientes y la problem´ atica de integrar eventos de distintas fuentes. Desde el punto de vista interno, las personas y equipos que forman parte del H2CS dispondr´ ıan de un cuadro de mandos para visualizar el estado actual de los compromisos adquiridos como parte de la ejecuci´ on del H2CS. Un componente de gesti´ on de negocio que permita incorporar pol´ ıticas de gobierno para la generaci´ on de pol´ ıticas de precio automatizadas que puedan ser incorporadas al portal de auto-provisionamiento. As´ ımismo, se abordar´ a el uso de las t´ ecnicas y herramientas de an´ alisis desarrolladas en el PT1 para dar soporte a la toma de decisi´ on sobre los costes de operaci´ on desde dos perspectivas: desde el punto de vista de la infraestructura, a la hora de gestionar el proceso de compra del IaaS m´ as adecuado en base a las necesidades de operaci´ on por parte del H2CS manteniendo los SLAs adquiridos con los clientes; desde el punto de vista de las personas involucradas en el 36 2.7. PLAN DE TRABAJO desarrollo, para definir los incentivos y penalizaciones para los individuos y equipos. Un componente de gesti´ on inteligente de la operaci´ on, que abordar´ a el uso de t´ ecnicas de predicci´ on para detectar posibles problemas de rendimiento o de cumplimiento del SLA en tiempo real y la definici´ on de reglas de actuaci´ on para guiar o automatizar las acciones sobre la infraestructura y los equipos bas´ andose en las predicciones obtenidas y en simulaciones de situaciones futuras. En particular, se prestar´ a especial atenci´ on a las reglas relativas a la elasticidad, que gestionar´ ıan el escalado y des-escalado de los sistemas computacionales y humanos que componen el H2CS para poder optimizar el coste de operaci´ on acordado, acotando el riesgo de incumplimiento de los SLAs, y teniendo en cuenta las penalizaciones e incentivos definidos por clientes, individuos y equipos. Tareas: Tarea 4.1. Desarrollo del componente de gesti´ on de acuerdos y las t´ ecnicas de monitorizaci´ on e integraci´ on de eventos. Tarea 4.2. Desarrollo del componente de gesti´ on de negocio y mecanismos de gesti´ on del proceso de compra y la definici´ on de incentivos y penalizaciones en personas. Tarea 4.3. Desarrollo de t´ ecnicas de predicci´ on para la detecci´ on de problemas de rendimiento y de cumplimiento de SLAs en tiempo real. Tarea 4.4. Desarrollo de reglas de actuaci´ on con especial atenci´ on a la elasticidad del servicio. Justificaci´on de contrataci´on de personal: Para poder abordar este paquete de trabajo con ´ exito es necesario disponer de un ingeniero con conocimientos amplios acerca de Complex Event Processing, servicios IaaS y plataformas de ejecuci´ on como Docker. Tambi´ en ser´ ıa deseable que tuviese conocimiento de algoritmos de machine learning. Paquete de trabajo 5: Casos de uso de servicios H2CS Objetivos: Los asociados al OBJ6. 37 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON Contribuciones principales: Validaci´ on de la aplicabilidad y utilidad de los resultados de investigaci´ on generados en los PT anteriores por medio de (1) puesta en pr´ actica los resultados en EXEMPLAR, un H2CS real, desarrollado, usado y operado por el propio grupo de investigaci´ on, y (2) la realizaci´ on de las actividades del proceso de seguimiento (ver secci´ on §2.6) para la aplicaci´ on de los resultados en casos de uso espec´ ıficos propuestos por las EPOs y la definici´ on de actividades de transferencia de tecnolog´ ıa a partir de ellos. Descripci´on: A diferencia de los PT anteriores, en este PT se engloban principalmente las tareas de seguimiento asociadas a los casos de uso a realizar con las EPOs y las tareas de pretransferencia y seguimiento para su aplicaci´ on en EXEMPLAR. Por un lado, se aplicar´ an los resultados del proyecto para el desarrollo de EXEMPLAR. Esta herramienta es un H2CS, puesto que da soporte la gesti´ on de estudios experimentales en cualquier ´ area de conocimiento. Esto implica la integraci´ on de servicios computacionales y prestados por humanos. Por ejemplo, los servicios de an´ alisis y almacenamiento de datos son servicios puramente computacionales integrados en EXEMPLAR. Por el contrario, los workflows asociados a la propia experimentaci´ on son servicios realizados por humanos. Pretendemos, aplicar los resultados del proyecto para dise˜ nar el acuerdo de nivel de servicio de EXEMPLAR y regular su uso y operaci´ on a trav´ es del mismo. Como complemento a esta actividad, se evaluar´ a la aplicabilidad de los resultados del proyecto a otras herramientas desarrolladas por el grupo que no son H2CS, como por ejemplo STATService (un servicio ´ unicamente computacional para el an´ alisis estad´ ıstico de datos). Esto permitir´ a evaluar la utilidad y rango de aplicabilidad de los resultados en otros tipos de sistemas. Por otro lado, se realizar´ an las tareas del proceso de seguimiento relacionadas con la identificaci´ on de otros casos de estudio espec´ ıficos propuestos en coordinaci´ on con las EPOs del proyecto y se buscar´ an los instrumentos de transferencia m´ as adecuado para materializarlo en caso de que se estime conveniente. En la siguiente tabla resumimos nuestra expectativa sobre las ´ areas de inter´ es de las EPOs del proyecto con respecto a los PT. El detalle de esta tabla se encuentra en el documento de solicitud del proyecto. En cuanto a nuestras expectativas sobre la transferencia de tecnolog´ ıa con estas 38 2.7. PLAN DE TRABAJO ´ Areas de inter´es de las EPOs EPO Transferencia Accenture PT1 Everis PT4 Isoin PT4 Isotrol Cupenya PT4 Selectomer PT2 Foulders PT1, PT2, PT4 Drupal PT3 SAS Icinetic PT2, PT4 Muchoviaje PT1, PT4 Inpro Cuadro 2.1: ´ Areas de Inter´ es de las EPOs del Proyecto con respecto a los PTs EPOs, ´ estas se concreta en una o varias de estas actividades: firmar contratos de I+D, movilidad de recursos humanos y alcanzar acuerdos estrat´ egicos de comercializaci´ on a trav´ es de una spin-off del grupo. M´ as detalles se pueden encontrar en la secci´ on §2.10.3. De entre todas ellas, queremos destacar la colaboraci´ on con Icinetic ya que es el que puede tener el alcance de mayor calado. En concreto, Icinetic est´ a interesada en los resultados que se esperan del proyecto BELI en particular, en los resultados relacionados con la evoluci´ on de la herramienta IDEAS para su integraci´ on con Hive- Cell (http://hivecell.io/), producto liderado/desarrollado por Icinetic para la construcci´ on de microservicios. HiveCell forma parte de una iniciativa estrat´ egica de Icinetic m´ as amplia orientada al desarrollo de aplicaciones basadas en micro-servicios en la que ya han desarrollado alianzas con las compa˜ n´ ıas de gesti´ on de APIs “3Scale” , “Apigee” y “Layer 7” y consideran que los resultados del proyecto BELI ser´ ıan muy innovadores y podr´ ıan ser utilizados como base en la construcci´ on de plataformas alternativas para conseguir sistemas aut´ onomos con una mayor ventaja competitiva sobre los existentes en la industria en dos l´ ıneas. 39 CAP´ ITULO 2. PROYECTO DE INVESTIGACI ´ ON Tareas: Tarea 5.1 Aplicaci´ on de resultados en servicios H2CS como EXEMPLAR. Tarea 5.2 Aplicaci´ on de resultados en servicios no H2CS como STATService. Tarea 5.3 Demostraciones a las EPOs. Tarea 5.4 Descripci´ on y selecci´ on de casos de uso de aplicaci´ on con las EPOs. Tarea 5.5 B´ usqueda del instrumento de transferencia m´ as adecuado para cada EPO y caso de estudio. 2.8 JUSTIFICACI ´ ON DE CONTRATACI ´ ON DE PERSONAL El desarrollo de estos PT requiere implementar pruebas de concepto y construir o ampliar herramientas software como parte del proceso de pre-transferencia. En concreto, se espera obtener y/o actualizar al menos 5 herramientas software. Partiendo de la experiencia obtenida en otros proyectos de similares caracter´ ısticas, las necesidades identificadas en cada paquete y las posibles sinergias entre estos, para apoyar el dise˜ no y desarrollo de estas herramientas proponemos un equipo de tres ingenieros durante dos a˜ nos y medio. 2.9 PLAN DE RIESGOS A continuaci´ on se resume un plan de riesgo com´ un a todos los objetivos. Falta de inter´es de una EPO: El entorno altamente din´ amico de las empresas tecnol´ ogicas, puede llevar a alguna EPO a perder inter´ es en los resultados del proyecto. Con m´ as de 10 EPOs la falta de inter´ es de una EPO no es substancial en el desarrollo del proyecto, pero en cualquier caso, sabiendo que en todos los proyectos gestionados por el grupo siempre se ha logrado incorporar nuevas EPOs, buscar´ ıamos otra EPO de dominio similar. 40 2.10. IMPACTO ESPERADO DE LOS RESULTADOS Dificultad para encontrar personal cualificado (probabilidad media): Las caracter´ ısticas cient´ ıfico-t´ ecnicas del proyecto complica encontrar personas con las caracter´ ısticas adecuadas, lo que se traducir´ a en un retraso en el comienzo de determinadas tareas debido al tiempo adicional invertido en formaci´ on. Para mitigar este riesgo el plan de formaci´ on (secci´ on §2.6) se ha dise˜ nado para ser eficaz y eficiente. Baja de un t´ecnico de apoyo (probabilidad media): El mercado laboral en tecnolog´ ıas de la informaci´ on puede ofrecer opciones atractivas al personal t´ ecnico que le lleven a rescindir su contrato. En tal caso se abrir´ a un proceso de selecci´ on a resolver en menos de 30 d´ ıas y el nuevo t´ ecnico se incorporar´ a al plan de formaci´ on establecido. Desde hace varios a˜ nos el grupo intenta mantener al menos un t´ ecnico con experiencia que acelere el proceso de formaci´ on, sobretodo, en lo relativo al uso del ecosistema de desarrollo del grupo, el cual requiere varias semanas de aprendizaje hasta ser plenamente competente. Riesgos relacionados con la investigaci´on (probabilidad muy baja): Riesgos tales como hip´ otesis invalidadas o estudios emp´ ıricos contradictorios no son considerados vitales para el proyecto. Por un lado, el equipo cuenta con amplia experiencia en tem´ aticas relacionadas con las del proyecto por lo que la pertinencia y validez de las hip´ otesis est´ an contrastadas. Por otro lado, el equipo aplica el paradigma de investigaci´ on conocido como design-science, que propone dise˜ nar artefactos novedosos a trav´ es de actividades iterativas de dise˜ no y evaluaci´ on. Esta iteratividad acota el riesgo al reorientar los siguientes ciclos de dise˜ no en caso de encontrar problemas conceptuales en una iteraci´ on previa. No obstante, el equipo de investigaci´ on vigilar´ a que el redise˜ no no exceda el tiempo previsto en su planificaci´ on. 2.10 IMPACTO ESPERADO DE LOS RESULTADOS 2.10.1 Impacto cient´ıfico-t´ecnico social y/o econ´omico BELI busca soluciones cient´ ıfico-t´ ecnicas que permitan resolver problemas planteados en el contexto del Reto en Econom´ ıa y Sociedad Digital. La tecnolog´ ıa generada 41 BIBLIOGRAF´ IA [30] P. Leitner, J. Ferner, W. Hummer, and S. Dustdar. Data-driven and automated prediction of service level agreement violations in service compositions. Distrib. Parallel Databases, 31(3):447 – 470, 2013. [31] H. Liu, F. Kuo, D. Towey, and T. Chen. How effectively does metamorphic testing alleviate the oracle problem? IEEE Trans. Soft. Eng., 40(1):4 – 22, 2014. [32] R. L´ opez-Herrej´ on, L. Linsbauer, J. Galindo, J. Parejo, D. Benavides, S. Segura, and A. Egyed. An assessment of search-based techniques for reverse engineering feature models. J. System and Software, 103:353 – 369, 2015. [33] C. Marquezan, A. Metzger, R. Franklin, and K. Pohl. Runtime management of multi-level SLAs for transport and logistic services. In 12th Intl. Conf. on Service- Oriented Computing (ICSOC), volume 8831, pages 560 – 574, Paris, France, 2014. [34] O. Mart´ ın-D´ ıaz, P. Fern´ andez, J. Garc´ ıa, and A. Ruiz-Cort´ es. Towards a comprehensive purchasing model for cloud services. In XI Jornadas de Ciencias e Ingenier´ıa de Servicios (JCIS), 2015. [35] A. Metzger, P. Leitner, D. Ivanovic, E. Schmieders, R. Franklin, M. Carro, S. Dustdar, and K. Pohl. Comparing and combining predictive business process monitoring techniques. IEEE Trans. Syst. Man. Cybern. Syst., 45(2):276 – 290, 2015. [36] D. Moldovan, G. Copil, H. Truong, and D. Schahram. MELA: Elasticity analytics for cloud services. Int. J. Big Data Intell., 2(1):45 – 62, 2015. [37] C. M¨ uller, M. Oriol, X. Franch, J. Marco, M. Resinas, A. Ruiz-Cort´ es, and M. Rodr´ ıguez. Comprehensive explanation of SLA violations at runtime. IEEE Trans. Serv. Computing, 7(2):163 – 183, 2014. [38] C. M¨ uller, M. Resinas, and A. Ruiz-Cort´ es. Automated analysis of conflicts in WS-Agreement. IEEE Trans. Service Computing, 7(4):530 – 544, 2014. [39] J. Offutt and W. Xu. Generating test cases for web services using data perturbation. ACM SIGSOFT Softw. Eng. Notes, 29(5):1, 2004. [40] J. Ortega y Gasset. Misi´on de la Universidad. 1930. 48 BIBLIOGRAF´ IA [41] M. Palacios, J. Garc´ ıa-Fanjul, J. Tuya, and G. Spanoudakis. Coverage-based testing for service level agreements. IEEE. Trans. Serv. Comput., 8(2):299 – 313, 2015. [42] M. Palacios, J. Garc´ ıa-Fanjul, J. Tuya, and G. Spanoudakis. Automatic test case generation for WS-Agreement using combinatorial testing. Comput. Stand. Interfaces, 38:84 – 100, 2015. [43] J. Parejo, A. Guti´ errez, P. Fern´ andez, and A. Ruiz-Cort´ es. FAST-SE: An ESB-based framework for SLA trading. Artif. Intell. Lect. Notes Bioinformatics, 5900:643 – 644, 2009. [44] J. Parejo, P. Fern´ andez, A. Ruiz-Cort´ es, and J. Garc´ ıa. SLAWs: Towards a conceptual architecture for SLA enforcement. In 2008 IEEE Congress on Services - Part I, pages 322 – 328, 2015. [45] C. Pautasso. RESTfull web service composition with BPEL for REST. Data Knowl. Eng., 68(9):851 – 866, 2009. [46] J. Pe˜ na, M. Hinchey, M. Resinas, R. Sterritt, and J. Rash. Designing and managing evolving systems using a MAS product lines approach. Sci. Comput. Program., 66 (1):71 – 86, 2007. [47] J. Pe˜ na-Siles, M. Gonz´ alez-Zamora, and J. Machuca. Specifying business services: learning from software engineering. J. Serv. Manag., 23(1):97 – 119, 2012. [48] A. Rogge-Solti and M. Weske. Prediction of business process durations using non- Markovian stochastic Petri nets. Inf. Syst., 54:1 – 14, 2015. [49] G. Rothermel, R. Untcn, C. Chu, and M. Harrold. Prioritizing test cases for regression testing. IEEE Trans. Softw. Eng., 27(10):929 – 948, 2001. [50] Science and B. Media. Systems and software variability management: concepts, tools and experiences, 2013. [51] S. Segura, J. Parejo, R. Hierons, D. Benavides, and A. Ruiz-Cort´ es. Automated generation of computationally hard feature models using evolutionary algorithms. Expert Systems, 41(8):3975 – 3992, 2014. 49 BIBLIOGRAF´ IA [52] S. Segura, A. S´ anchez, and A. Ruiz-Cort´ es. Automated variability analysis and testing of an E-commerce site. In 29th ACM/IEEE Intl. Conf. on Automated Software Engineering (ASE), pages 139 – 150, 2014. [53] S. Segura, A. Dur´ an, A. S´ anchez, D. Le-Berrie, L. Lonca, and A. Ruiz-Cort´ es. Automated metamorphic testing of variability analysis tools. Software Testing, Verif. Reliab., 25(2):138 – 163, 2015. [54] C. Sun, G. Wang, B. Mu, H. Liu, Z. Wang, and T. Chen. A metamorphic relationbased approach to testing web services without oracles. Int. J. Web Serv. Res., 9(1): 51 – 73, 2012. [55] A. S´ anchez, S. Segura, and A. Ruiz-Cort´ es. A comparison of test case priorization criteria for software product lines. In IEEE Int. Conf. Software Testing, Verification and Validation, pages 41 – 50, 2014. [56] A. S´ anchez, S. Segura, J. Parejo, and A. Ruiz-Cort´ es. Variability testing in the wild: the Drupal case study. Software System Model, pages 1 – 22, 2015. [57] M. Toro. La Inform´atica: una Ingenier´ıa joven muy importante. Textos institucionales. Secretariado de publicaciones de la Universidad de Sevilla, 2014. [58] H. Truong and S. Dustdar. Programming elasticity in the cloud. Computer (Long Beach Calif.), 48(3):87 – 90, 2015. [59] R. Uriarte, F. Tiezzi, and R. De-Nicola. SLAC: A formal service-level agreement language for cloud computing. In IEEE/ACM Int. Conf. on Utility and Cloud Computing (UCC), pages 419 – 426, 2014. [60] M. Utting and B. Legeard. Practical model testing: A tools approach, 2007. [61] A. Vallecillo. Los siguientes 10 a˜ nos en ingenier´ ıa de software: Retos y oportunidades. NovATIca, (234):90–94, 2015. [62] W. van-der Aalst. Configurable services in the cloud: supporting variability while enabling cross-organizational process mining. In On the move to meaningful Internet Systems: OTM 2010, pages 8 – 25, 2010. 50 PROGRAMAS DOCENTES PARTE II 3 PROGRAMA DE “SISTEMAS ORIENTADOS A SERVICIOS” 53 3.1 CONSIDERACIONES GENERALES En el Proyecto Docente e Investigador se ha presentado la relaci´ on de asignaturas que conforman el perfil de la plaza. Corresponde a este cap´ ıtulo perfilar y desarrollar el contenido de la asignatura “Sistemas Orientados a Servicios”’. Para ello, nos proponemos presentar un programa completo que recoge los distintos condicionantes que se han analizado en dicho proyecto. Conviene recordar los condicionantes temporales y de audiencia de la asignatura antes de realizar el desarrollo de la misma: se trata de una asignatura optativa del segundo cuatrimestre del tercer curso del Grado en Ingenier´ ıa Inform´ atica-Tecnolog´ ıas Inform´ aticas que tiene asignada una carga lectiva de 6 ECTS. Debido a la naturaleza optativa el n´ umero de alumnos matriculados permite que la totalidad de la asignatura se imparta en aulas con ordenadores disponibles para los alumnos, lo cual permite implementar las actividades formativas contempladas en nuestra metodolog´ ıa (v´ ease Secci´ on §3.4). El resto del cap´ ıtulo mantiene la estructura y recomendaciones de estilo de “Proyecto Docente” que fija la actual normativa de la Universidad de Sevilla, para la cual el concepto de “Programa Docente” se reserva para una versi´ on m´ as reducida y general que idealmente debe tener una vigencia cercana a la del Plan de Estudios. En este sentido creemos oportuno se˜ nalar que ni el Proyecto ni el Programa Docente exige indicar las recomendaciones sobre los conocimientos m´ ınimos que se debieran tener, ni las asignaturas recomendadas cursar al mismo tiempo. CAP´ ITULO 3. PROGRAMA DE “SISTEMAS ORIENTADOS A SERVICIOS” 3.2 OBJETIVOS Y COMPETENCIAS Objetivos docentes espec´ıficos: La asignatura se centra en el dise˜ no y construcci´ on de aplicaciones con enfoque orientado a servicios. De manera espec´ ıfica, en base a la evoluci´ on de la industria del software hacia un modelo de software como servicio (SaaS), esta asignatura plantea un enfoque que permita a los alumnos interiorizar los aspectos fundamentales que se precisan para construir aplicaciones con arquitectura de microservicios; este paradigma arquitect´ onico est´ a considerado actualmente en la industria como el modelo predominante debido a que tiene un conjunto de beneficios tales como: optimizaci´ on de la escalabilidad, flexibilidad de extensi´ on/evoluci´ on y facilidad de integraci´ on. Competencias transversales/gen´ericas: G01. Capacidad para concebir, redactar, organizar, planificar, desarrollar y firmar proyectos en el ´ ambito de la ingenier´ ıa en inform´ atica que tengan por objeto, de acuerdo con los conocimientos adquiridos, la concepci´ on, el desarrollo o la explotaci´ on de sistemas, servicios y aplicaciones inform´ aticas. G04. Capacidad para definir, evaluar y seleccionar plataformas hardware y software para el desarrollo y la ejecuci´ on de sistemas, servicios y aplicaciones inform´ aticas. G05. Capacidad para concebir, desarrollar y mantener sistemas, servicios y aplicaciones inform´ aticas empleando los m´ etodos de la ingenier´ ıa del software como instrumento para el aseguramiento de su calidad. G06. Capacidad para concebir y desarrollar sistemas o arquitecturas inform´ aticas centralizadas o distribuidas integrando hardware, software y redes. G08. Conocimiento de las materias b´ asicas y tecnolog´ ıas, que capaciten para el aprendizaje y desarrollo de nuevos m´ etodos y tecnolog´ ıas, as´ ı como las que les doten de una gran versatilidad para adaptarse a nuevas situaciones. Competencias espec´ıficas: 54 3.3. CONTENIDOS DE LA ASIGNATURA E25. Capacidad de integrar soluciones de Tecnolog´ ıas de la Informaci´ on y las Comunicaciones y procesos empresariales para satisfacer las necesidades de informaci´ on de las organizaciones, permiti´ endoles alcanzar sus objetivos de forma efectiva y eficiente, d´ andoles as´ ı ventajas competitivas. E27. Capacidad para participar activamente en la especificaci´ on, dise˜ no, implementaci´ on y mantenimiento de los sistemas de informaci´ on y comunicaci´ on. E30. Capacidad para comprender y aplicar los principios y las t´ ecnicas de gesti´ on de la calidad y de la innovaci´ on tecnol´ ogica en las organizaciones. E32. Capacidad para seleccionar, dise˜ nar, desplegar, integrar, evaluar, construir, gestionar, explotar y mantener las tecnolog´ ıas de hardware, software y redes, dentro de los par´ ametros de coste y calidad adecuados E36. Capacidad de concebir sistemas, aplicaciones y servicios basados en tecnolog´ ıas de red, incluyendo Internet, web, comercio electr´ onico, multimedia, servicios interactivos y computaci´ on m´ ovil. 3.3 CONTENIDOS DE LA ASIGNATURA En esta asignatura se aborda un enfoque de Aprendizaje basado en Proyectos (ABP) por equipos (de 2-3 personas) donde el cada equipo debe desarrollar un proyecto diferente que ponga en pr´ actica los conocimientos adquirido en la asignatura de forma aplicada de manera espec´ ıfica a su proyecto. Siguiendo el paradigma de construcci´ on de la programaci´ on ´ agil, el proyecto que se realiza corresponde con una aplicaci´ on que debe satisfacer un conjunto de requisitos funcionales y no funcionales que pueden abordarse en varios entregables y que se construyen siguiendo un desarrollo evolutivo. De esta forma, cada entrega siempre resulta en una aplicaci´ on operativa que en los primeros entregables posee una funcionalidad escasa y a la que se van a˜ nadiendo componentes o funcionalidades en cada entregable posterior. Este enfoque constructivista permite al estudiante visualizar lo antes posible el resultado pr´ actico de la aplicaci´ on de sus conocimientos y c´ omo se encadenan y vertebran los nuevos conceptos sobre conocimiento asentado; estos dos 55 CAP´ ITULO 3. PROGRAMA DE “SISTEMAS ORIENTADOS A SERVICIOS” aspectos persiguen potenciar la motivaci´ on del alumno y premiar el trabajo continuo para desincentivar el abandono de la asignatura. Bajo este enfoque, la cl´ asica distinci´ on entre clases de teor´ ıa y clases de pr´ acticas o laboratorio no es directamente aplicable, consider´ andose las distintas sesiones o actividades formativas como una mezcla entre aspectos te´ oricos y pr´ acticos orientados a que los alumnos adquieran las competencias necesarias para llevar a cabo el proyecto. Todas los elementos empleados en la metodolog´ ıa docente (sesiones, actividades y entregables) est´ an identificados de manera un´ ıvoca con un patr´ on definido por un prefijo y dos d´ ıgitos. En concreto, los tipos de elementos que se desarrollan en la asignatura son: Cxx (Clase Integral): Sesiones donde se presentan conocimientos y se hacen ejercicios sint´ eticos de baja complejidad. Fxx (Sesi´on de Feedback): Sesiones donde se realizan Micro-Tests y se verifica que se han realizado el trabajo y entregables planificados. MTx (Micro-test): Tests con un conjunto reducido de preguntas (normalmente 5 preguntas). Dxx (Entregable): Artefacto(s) que se debe presentar en una fecha espec´ ıfica (normalmente una aplicaci´ on operativa acompa˜ nada de documentaci´ on). RTx (Mesa redonda): Mesas redondas donde se realiza una reflexi´ on y an´ alisis conjunto sobre alguna tem´ atica. Los grandes bloques tem´ aticos en los que se divide la asignatura son los siguientes: 1. Introducci´ on a la asignatura 2. Ecosistema de desarrollo 3. Dise˜ no e Implementaci´ on de microservicios RESTful 4. Integraci´ on y visualizaci´ on de datos mediante servicios 5. Acuerdos de Nivel de Servicio 56 3.4. ACTIVIDADES FORMATIVAS 3.3.1 Relaci´on detallada y ordenaci´on temporal de los contenidos Las asignatura se ha desarrollado en un conjunto de 15 semanas, en cada una de las cuales existen 2 sesiones que, de manera general, corresponden con una sesi´ on de Clase Integral (CXX) y una sesi´ on de Feedback (FXX). La planificaci´ on detallada de sesiones se puede ver en el Cuadro §3.1, en el cual se aprecia que las dos primeras semanas de la asignatura son ´ unicamente de clases integrales y las dos ´ ultimas son de feedback. Es recomendable que la secuenciaci´ on habitual se estructure de forma que el tiempo entre la finalizaci´ on de la clase integral y el comienzo de la sesi´ on de feedback sea mayor que el del que transcurre entre el fin del feedback y el comienzo de la clase integral. (Por ejemplo si las sesiones deben ser martes y mi´ ercoles, es recomendable que el martes se dedique a feedback y el mi´ ercoles a clase integral). 3.3.2 Publicaci´on del material docente Al final de cada semana, el material que se entrega a los alumnos es el siguiente: Video de la sesi´ on de clase integral (excluyendo las partes donde se comentan las soluciones a los micro-tests). Presentaci´ on te´ orica utilizada durante las clases. Nueva secci´ on de backlog donde se abordan los aspectos que se van a requerir en la siguiente sesi´ on de feedback. El backlog consiste en un documento online en constante evoluci´ on durante el curso, en el que se van a˜ nadiendo todas las tareas que los alumnos deben ir realizando, incluyendo tareas opcionales que permitan obtener una puntuaci´ on extra para la evaluaci´ on final. 3.4 ACTIVIDADES FORMATIVAS Las actividades formativas que se proponen son: clases integral, sesiones de feedback y mesas redondas. A continuaci´ on se indican las horas presenciales y no presenciales, junto con la metodolog´ ıa de ense˜ nanza y aprendizaje para cada una de ellas. 57 CAP´ ITULO 3. PROGRAMA DE “SISTEMAS ORIENTADOS A SERVICIOS” 3.5.3 Informaci´on adicional Todas las referencias bibliogr´ aficas est´ an disponibles en la biblioteca de la Universidad de Sevilla o disponible en su Plataforma de Ense˜ nanza Virtual. Asimismo, en el propio backlog de la asignatura utilizado para describir las tareas a realizar se proporcionan enlaces a referencias ´ utiles para el desarrollo de dichas tareas. Por otra parte, con el fin de dar soporte a la metodolog´ ıa docente, se utilizan los siguientes recursos y herramientas: Github: github.com Piazza: piazza.com Toggle: toggl.com Ense˜ nanza Virtual: ev.us.es Opera: opera.eii.us.es Google Drive: www.google.com/intl/es_es/drive Nodejs: nodejs.org 3.6 SISTEMAS Y CRITERIOS DE EVALUACI ´ ON Y CALIFICACI ´ ON 3.6.1 Sistema de evaluaci´on A lo largo de la asignatura, se plantea una evaluaci´ on incremental que puede ser visualizada en cada momento por el alumno; de esta forma el alumno percibe como su nota va incrementando de manera gradual cada semana en base al trabajo realizado y los conocimientos demostrados. Las actividades que tienen asociado una evaluaci´ on son las siguientes: Micro Tests. Estos tests tienen una nota m´ axima de 0,2 puntos y est´ an compuestos de 5 preguntas (0,05 ptos por pregunta) con una penalizaci´ on del 100% en caso de respuesta incorrecta (-0,05 ptos por respuesta incorrecta). A fin de tener un 64 3.6. SISTEMAS Y CRITERIOS DE EVALUACI ´ ON Y CALIFICACI ´ ON acercamiento incremental al sistema de evaluaci´ on durante las primeras sesiones de feedback, en caso de obtener una puntuaci´ on total negativa en el MT, no se restaba a la nota global. Cumplimiento del conjunto de la lista de verificaci´ on de una sesi´ on de feedback. En caso de cumplirse la totalidad de los controles, se considera que existe un feedback positivo y se otorga 0,1 puntos. Si alguno de los controles no se cumple, se considera que el feedback es negativo y no se suma ninguna cantidad. En el caso de que existan dos feedbacks negativos consecutivos se establece una penalizaci´ on de -0,2 puntos.; esta penalizaci´ on incentiva a los alumnos que han tenido un feedback negativo a intentar recuperarse en el siguiente feedback. Al igual que en el caso de los MT, durante las primeras sesiones de feedback, se relaja esta penalizaci´ on para tener un acercamiento incremental al mecanismo de evaluaci´ on. En el caso de que durante el mecanismo de comprobaci´ on cruzada el profesor detecte que un revisor no ha realizado su trabajo correctamente, se considera que el revisor tiene feedback negativo con las mismas penalizaciones a todos los efectos. Entregables. Los distintos artefactos son entregados durante el curso y tienen una peso incremental de manera que el esfuerzo requerido para desarrollarlo tiene una complejidad creciente. El ´ ultimo entregable (D04) se realiza en la ´ ultima semana de clase y tiene una evaluaci´ on singular. Adem´ as de una entrega de artefactos D04.A, D04.B y D04.C), se realiza una defensa individual (D04.D) a la que corresponde el m´ aximo peso de la asignatura. En esta defensa individual, el alumno demuestra que tiene un alto grado de conocimiento sobre el artefacto entregado; para ello, se establecen un conjunto de ejercicios que tiene que desarrollar de manera pr´ actica sobre el artefacto (p,e, establecer hip´ otesis sobre el comportamiento en caso de situaciones singulares o ser capaz de predecir el flujo de ejecuci´ on de los algoritmos m´ as complejos). 3.6.2 Criterios de calificaci´on En el Cuadro §3.2 se desglosa de manera detallada el peso de cada uno de los elementos evaluables durante la primera convocatoria del curso 2015/2016. En este caso 65 CAP´ ITULO 3. PROGRAMA DE “SISTEMAS ORIENTADOS A SERVICIOS” Elemento Nota Individual Cantidad Nota Total Micro-tests 0,2 7 1,4 Feedbacks 0,1 12 1,2 D01 0,4 D02 0,8 D03 1,0 RT01 0,2 D04.A 0,3 D04.B 0,5 D04.C 1,0 D04.D 3,3 Total 10 Cuadro 3.2: Esquema de evaluaci´ on de SOS se puede observar que se ha realizado un total de 7 Micro-Tests y 12 sesiones de feedback. Una gran parte de la nota (aproximadamente un 75%) corresponde con los 4 entregables desarrollados. Cabe destacar como el ´ ultimo entregable (D04) corresponde con el 50% de la nota de manera que, en la pr´ actica se fuerza al estudiante a realizar la ´ ultima entrega para poder conseguir el aprobado en la asignatura. La nota final para la primera convocatoria se corresponder´ a con la suma de todos los elementos de calificaci´ on del Cuadro §3.2, adem´ as de posibles actividades extras que se proponen durante el curso, las cuales s´ olo se tendr´ an en cuenta en el caso de que la calificaci´ on de los elementos anteriores sea superior a 5. Para la segunda y tercera convocatoria, la evaluaci´ on se realiza mediante la entrega y defensa de un proyecto completo con los mismos requisitos exigidos en la primera convocatoria, con la restricci´ on adicional de tener que ser un proyecto completamente diferente a los presentados en la primera convocatoria. En estos casos la nota final se calcula dando un peso de 5 puntos a un test de 20 preguntas sobre todo el contenido de la asignatura y otros 5 puntos a la defensa realizada, con el mismo criterio que el usado para el D04 en la primera convocatoria. 66 4 PROGRAMA DE “ARQUITECTURA EINTEGRACI ´ ON DE SISTEMAS SOFTWARE” 67 4.1 CONSIDERACIONES GENERALES En el Proyecto Docente e Investigador se ha presentado la relaci´ on de asignaturas que conforman el perfil de la plaza. Corresponde a este cap´ ıtulo perfilar y desarrollar el contenido de la asignatura “Arquitectura e Integraci´ on de Sistemas Software”. Para ello, nos proponemos presentar un programa completo que recoge los distintos condicionantes que se han analizado en dicho proyecto. Conviene recordar los condicionantes temporales y de audiencia de la asignatura antes de realizar el desarrollo de la misma: se trata de una asignatura obligatoria del segundo cuatrimestre del segundo curso del Grado en Ingenier´ ıa Inform´ atica-Ingenier´ ıa del Software que tiene asignada una carga lectiva de 6 ECTS de las que 3.6 cr´ editos se imparten a un grupo “grande” (50-70 alumnos) para el que no existen garant´ ıas que se pueda impartir en un aula con ordenadores, y otros 2.4 cr´ editos a un grupo “peque˜ no” (22-28 alumnos) para el que s´ ı se dispone de un aula con un ordenador para cada alumno. El resto del cap´ ıtulo mantiene la estructura y recomendaciones de estilo de “Proyecto Docente” que fija la actual normativa de la Universidad de Sevilla, para la cual el concepto de “Programa Docente” se reserva para una versi´ on m´ as reducida y general que idealmente debe tener una vigencia cercana a la del Plan de Estudios. En este sentido creemos oportuno se˜ nalar que ni el Proyecto ni el Programa Docente exige indicar las recomendaciones sobre los conocimientos m´ ınimos que se debieran tener, ni las asignaturas recomendadas cursar al mismo tiempo. CAP´ ITULO 4. ARQUITECTURA E INTEGRACI ´ ON DE SISTEMAS SOFTWARE 4.2 OBJETIVOS Y COMPETENCIAS Objetivos docentes espec´ıficos: El objetivo de esta materia es dotar a los alumnos de los conocimientos y competencias necesarios para enfrentarse al modelado y dise˜ no de software a nivel arquitect´ onico, aplicando distintos estilos y patrones arquitect´ onicos, y a la integraci´ on de aplicaciones y servicios software ya existentes. Competencias transversales/gen´ericas: G05. Capacidad para concebir, desarrollar y mantener sistemas, servicios y aplicaciones inform´ aticas empleando los m´ etodos de la ingenier´ ıa del software como instrumento para el aseguramiento de su calidad. G08. Conocimiento de las materias b´ asicas y tecnolog´ ıas, que capaciten para el aprendizaje y desarrollo de nuevos m´ etodos y tecnolog´ ıas, as´ ı como las que les doten de una gran versatilidad para adaptarse a nuevas situaciones. G09. Capacidad para resolver problemas con iniciativa, toma de decisiones, autonom´ ıa y creatividad. Capacidad para saber comunicar y transmitir los conocimientos, habilidades y destrezas de la profesi´ on de Ingeniero en Inform´ atica. Competencias espec´ıficas: E25. Capacidad para desarrollar, mantener y evaluar servicios y sistemas software que satisfagan todos los requisitos del usuario y se comporten de forma fiable y eficiente, sean asequibles de desarrollar y mantener y cumplan normas de calidad, aplicando las teor´ ıas, principios, m´ etodos y pr´ acticas de la Ingenier´ ıa del Software. E27. Capacidad de dar soluci´ on a problemas de integraci´ on en funci´ on de las estrategias, est´ andares y tecnolog´ ıas disponibles. E28. Capacidad de identificar y analizar problemas y dise˜ nar, desarrollar, implementar, verificar y documentar soluciones software sobre la base de un conocimiento adecuado de las teor´ ıas, modelos y t´ ecnicas actuales. 68 4.3. CONTENIDOS DE LA ASIGNATURA Blq. Tema T´ıtulo Horas 1Introducci´ on al desarrollo Web 4 2Introducci´ on a la Arquitectura del Software 2 3Arquitectura Web 2 I4Modelado de Arquitectura Software 2 II 5 Introducci´ on a la Integraci´ on 2 6Integraci´ on Web 2 7Servicios RESTful 4 8Patrones de Integraci´ on 2 9Pruebas de integraci´ on 2 Total 22 Cuadro 4.1: Temario de teor´ ıa propuesto para AISS 4.3 CONTENIDOS DE LA ASIGNATURA La asignatura est´ a estructurada en torno a dos grandes apartados: Arquitectura e Integraci´ on, que se organizan en una cl´ asica distribuci´ on de teor´ ıa (a impartir al grupo “grande”) y pr´ actica (a impartir al grupo “peque˜ no” en un aula de ordenadores). La relaci´ on detallada y ordenaci´ on temporal de sus contenidos se indica a continuaci´ on. 4.3.1 Programa de teor´ıa Tema 1: Introducci´on al desarrollo Web Objetivos docentes espec´ıficos: Que el alumno conozca y comprenda los conceptos te´ oricos b´ asicos sobre el desarrollo Web necesarios para aprovechar las clases de laboratorio. Contenido: 1.1 Conceptos b´ asicos: URL, HTTP, HTML, CSS, JavaScript. 1.2 Formatos de intercambio de datos: JSON y XML. 1.3 Definici´ on y ejemplos de AJAX. 1.4 Definici´ on de mashup. Ejemplos y repositorios. 1.5 Definici´ on de API Web. Ejemplos. Bibliograf´ıa b´asica: Tutoriales de la w3schools (www.w3schools.com/). Reposito- 69 CAP´ ITULO 4. ARQUITECTURA E INTEGRACI ´ ON DE SISTEMAS SOFTWARE rios online de mashups programmableweb (www.programmableweb.com/) y mashape (www.mashape.com/). Documentaci´ on de las APIs Web de Youtube (developers. google.com/youtube/v3) y Spotify (developer.spotify.com/web-api). Tema 2: Introducci´on a la Arquitectura del Software Objetivos docentes espec´ıficos: Que el alumno conozca el concepto de arquitectura del softwarey los tipoe de artefactos reutilizables m´ as comunes, y que comprenda los principios de dise˜ no arquitect´ onico. Contenido: 2.1 Arquitectura del software. Motivaci´ on, definici´ on, modelado, habilidades del arquitecto software. 2.2 Artefactos reutilizables: componentes, servicios web, librer´ ıa, framework. 2.3 Principios b´ asicos de dise˜ no: acoplamiento, cohesi´ on, separaci´ on de responsabilidades, variaciones protegidas. 2.4 Estilos y patrones arquitect´ onicos. Definici´ on y diferencia. 2.5 Estilos arquitect´ onicos concretos: centrado en datos, tuber´ ıas y filtros, capas, microservicios. Bibliograf´ıa b´asica: Pressman [10] cap´ ıtulos 1,2 y 14, Eeles and Cripps [5] cap´ ıtulos 1 y2,Spinellis and Gousios [12] cap´ ıtulo 1, Buschmann et al. [2] cap´ ıtulo 2, Bass et al. [1] cap´ ıtulos 1, 2 y 3. Bibliograf´ıa de consulta: Para las arquitecturas de microservicios se recomienda la lectura del art´ ıculo de James Lewis and Martin Fowler: http://martinfowler.com/ articles/microservices.html. Tema 3: Arquitectura Web Objetivos docentes espec´ıficos: Que el alumno conozca la arquitectura de sistemas de informaci´ on web, y comprenda las ventajas e inconvenientes de los principales estilos y patrones arquitect´ onicos aplicados en este tipo de arquitecturas: estilo arquitect´ onico en capas, el despliegue en m´ ultiples niveles, y el patr´ on arquitect´ onico Modelo-Vista- Controlador (MVC). Contenido: 70 4.3. CONTENIDOS DE LA ASIGNATURA 3.1 Sistemas de Informaci´ on Web. 3.2 Dise˜ no l´ ogico en capas. 3.3 Estrategias de dise˜ no: top-down, bottom-up. 3.4 Dise˜ no f´ ısico en niveles. 3.5 Patr´ on MVC. Bibliograf´ıa b´asica: Pressman [10] cap´ ıtulo 29, Eeles and Cripps [5] cap´ ıtulos 8 y 9, Spinellis and Gousios [12] cap´ ıtulos 3 y 5, Buschmann et al. [2] secci´ on 2.4, Bass et al. [1] cap´ ıtulo 26. Tema 4: Modelado de Arquitectura Software Objetivos docentes espec´ıficos: Que el alumno conozca la sintaxis de los diagramas UML de componentes y de despliegue,y que sepa aplicar dichos diagramas para para describir la arquitectura de las aplicaciones web y los escenarios de integraci´ on m´ as comunes. Contenido: 4.1 Introducci´ on a UML. 4.2 Diagramas UML de componentes. 4.3 Diagramas UML de despliegue. 4.4 Herramientas de modelado. Bibliograf´ıa b´asica: Pressman [10] cap´ ıtulos 14 y 22, Pilone and Pitman [9] cap´ ıtulos 5 y6,Cheesman and Daniels [3] cap´ ıtulo 1. Bibliograf´ıa de consulta: Para referencias sobre la especificaci´ on UML y ejemplos resulta ´ util la p´ agina de Kirill Fakhroutdinov: http://www.uml-diagrams.org. Tema 5: Introducci´on a la Integraci´on Objetivos docentes espec´ıficos: Que el alumno conoza los retos asociadas a la la integraci´ on de aplicaciones, y los escenarios m´ as comunes de integraci´ on. Adem´ as se pretende que el alumno conozca las estrategias de integraci´ on m´ as habituales y comprenda sus ventajas e inconvenientes, para pode aplicar aquellos que m´ as convengan dependiendo del contexto. Contenido: 71 CAP´ ITULO 4. ARQUITECTURA E INTEGRACI ´ ON DE SISTEMAS SOFTWARE 5.1 Motivaci´ on y definici´ on de integraci´ on de aplicaciones. 5.2 Aplicaciones distribuidas vs. integraci´ on de aplicaciones. 5.3 Integraci´ on de datos vs integraci´ on de aplicaciones. 5.4 Retos de la integraci´ on. 5.5 Escenario comunes de integraci´ on. 5.6 Estrategias tracionales de integraci´ on: transferencia de ficheros, bases de datos compartidas, invocaci´ on a procedimientos remotos y mensajer´ ıa. Bibliograf´ıa b´asica: Hohpe and Woolf [6]. Bibliograf´ıa de consulta: Para referencias sobre los distintos patrones de integraci´ on y escenarios concretos: http://www.enterpriseintegrationpatterns.com/. Tema 6: Integraci´on Web Objetivos docentes espec´ıficos: El objetivo de este tema es ense˜ nar los conceptos claves para la integraci´ on en la Web como la sindicaci´ on de contenidos, los servicios web o las aplicaciones web h´ ıbridas (mashups). Contenido: 6.1 Mashups. Definici´ on y ejemplos. 6.2 Sindicaci´ on de contenidos: RSS vs Atom. 6.3 Servicios web: SOAP vs REST. 6.4 APIs web. Definici´ on, ejemplos y buenas pr´ acticas. Bibliograf´ıa b´asica: Webber et al. [13] cap´ ıtulos 3 y 4, Daigneau [4] cap´ ıtulo 2. Bibliograf´ıa de consulta: Repositorios online de mashups programmableweb (http: //www.programmableweb.com/) y mashape (https://www.mashape.com/). Documentaci´ on de las APIs Web de Youtube (https://developers.google.com/ youtube/v3) y Spotify (https://developer.spotify.com/web-api). Para referencias sobre la sindicaci´ on de contenidos se recomienda el tutorial de la w3cschools (http://www.w3schools.com/xml/xml_rss.asp) y las propias especificaciones de RSS (http://cyber.law.harvard.edu/rss/rss.html) y ATOM (http:// www.ietf.org/rfc/rfc4287). 72 4.3. CONTENIDOS DE LA ASIGNATURA Tema 7: Servicios RESTful Objetivos docentes espec´ıficos: Que el alumno conozca el estilo arquitect´ onico REST y los servicios web RESTful. Que el alumno comprenda las ventajas e implicaciones de la aplicaci´ on de los principios REST para el desarrollo de sistemas distribuidos y la integraci´ on de implicaciones. Que el alumno conozca el formato Swagger para la documentaci´ on de APIs REST y sea capaz de aplicarlo a la documentaci´ on de las APIs usadas en las pr´ acticas. Contenido: 7.1 Estilo arquitect´ onico REST. Definici´ on y principios. 7.2 Protocolo HTTP. 7.3 Servicios web RESTful. 7.4 Buenas pr´ acticas para el dise˜ no de servicios RESTful. 7.5 Documentaci´ on de APIs RESTful con Swagger. Bibliograf´ıa b´asica: Webber et al. [13] cap´ ıtulos 3 y 4, Daigneau [4] cap´ ıtulo 2, Reese and Reilly [11], Masse [7]. Sitio web de Swagger (http://swagger.io/). Tema 8: Patrones de Integraci´on Objetivos docentes espec´ıficos: Que el alumno conozca los problemas que pueden los parones de integraci´ on presentar patrones de integraci´ on habituales y comprenda sus ventajas e inconvenientes. Contenido: 8.1 Motivaci´ on y definici´ on de patr´ on de integraci´ on. 8.2 Patrones b´ asicos. 8.3 Canales de mensajes. 8.4 Construcci´ on de mensajes. 8.5 Enrutamiento de mensajes. 8.6 Manipulaci´ on de mensajes. 8.7 Extremos de mensajer´ ıa. 8.8 Monitorizaci´ on. Bibliograf´ıa b´asica: Hohpe and Woolf [6]. Bibliograf´ıa de consulta: Para referencias sobre los distintos patrones de integraci´ on y escenarios concretos: http://www.enterpriseintegrationpatterns. 73 CAP´ ITULO 5. PROGRAMA DE “DISE ˜ NO Y PRUEBAS” 5.2 OBJETIVOS Y COMPETENCIAS Objetivos docentes espec´ıficos: El objetivo de esta materia es dotar a los alumnos de los conocimientos y competencias necesarios para aprender a transformar una especificaci´ on informal de requisitos de un sistema de informaci´ on web de peque˜ na o media escala en un sistema real utilizando tecnolog´ ıas, herramientas y m´ etodos habituales en nuestro entorno industrial. Competencias transversales/gen´ericas: G05. Capacidad para concebir, desarrollar y mantener sistemas, servicios y aplicaciones inform´ aticas empleando los m´ etodos de la ingenier´ ıa del software como instrumento para el aseguramiento de su calidad. G09. Capacidad para resolver problemas con iniciativa, toma de decisiones, autonom´ ıa y creatividad. Capacidad para saber comunicar y transmitir los conocimientos, habilidades y destrezas de la profesi´ on de Ingeniero T´ ecnico en Inform´ atica. Competencias espec´ıficas: E25. Capacidad para desarrollar, mantener y evaluar servicios y sistemas software que satisfagan todos los requisitos del usuario y se comporten de forma fiable y eficiente, sean asequibles de desarrollar y mantener y cumplan normas de calidad, aplicando las teor´ ıas, principios, m´ etodos y pr´ acticas de la Ingenier´ ıa del Software. E28. Capacidad de identificar y analizar problemas y dise˜ nar, desarrollar, implementar, verificar y documentar soluciones software sobre la base de un conocimiento adecuado de las teor´ ıas, modelos y t´ ecnicas actuales. E30. Capacidad para comprender y aplicar los principios y las t´ ecnicas de gesti´ on de la calidad y de la innovaci´ on tecnol´ ogica en las organizaciones. 80 5.3. CONTENIDOS DE LA ASIGNATURA Cuat. Lecci´on T´ıtulo Actividades Formativas(horas) Horas 1Introducci´ on TEO(2), PRO(1) 6 2Modelos de Dominio TEO(1), PRO(2), SEG(1) 8 3Modelos de Persistencia TEO(1), PRO(2), SEG(1) 8 14Repositorios y Servicios TEO(1), PRO(2), SEG(1) 8 5Vistas TEO(1), PRO(2), SEG(1) 8 6Controladores TEO(1), PRO(1), SEG(4) 12 7Despliegue TEO(1), PRO(1), SEG(4) 12 8Lecciones Aprendidas TEO(2), SEG(4) 12 9Pruebas Funcionales TEO(1), SEG(7) 16 210 Pruebas de Rendimiento TEO(1), SEG(3) 8 11 Pruebas de Aceptaci´ on TEO(1), SEG(3) 8 12 Hackathon SEG(7) 14 Total 120 Cuadro 5.1: Relaci´ on detallada y ordenaci´ on temporal de contenidos 5.3 CONTENIDOS DE LA ASIGNATURA La asignatura est´ a estructurada en torno a 12 lecciones como se muestra en la tabla §5.1, que se desarrollan mediante diferentes actividades formativas comprendiendo clases te´ oricas (TEO - docencia te´ orica en aula, a impartir al grupo “grande”), clases de problemas o pr´ acticas en aula (PRO - actividad pr´ actica en aula orientada a la aplicaci´ on de conocimientos a situaciones concretas como estudio de casos o resoluci´ on de problemas, a impartir al grupo “grande” o “peque˜ no” en funci´ on del aula disponible), y otras de seguimiento del proyecto que podr´ ıan englobarse en las pr´ acticas de laboratorios (SEG - actividades desarrolladas en espacios con equipamiento especializado, a impartir al grupo “peque˜ no”). La relaci´ on detallada y ordenaci´ on temporal de sus contenidos se indica a continuaci´ on. Cabe destacar que cada lecci´ on tendr´ a una duraci´ on acorde a su complejidad y ser´ a evaluada al t´ ermino de la misma con un entregable que los estudiantes tendr´ an que realizar como integrantes de un grupo de trabajo. 81 CAP´ ITULO 5. PROGRAMA DE “DISE ˜ NO Y PRUEBAS” 5.3.1 Lecci´on 1: Introducci´on Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumnos conozca la asignatura, el entorno de trabajo y la arquitectura de un sistema de informaci´ on web t´ ıpico. La entrega asociada con esta lecci´ on tiene como ´ unico objetivo que los alumnos se familiaricen con los conceptos principales y sean capaces de instanciar un espacio de trabajo y la plantilla de proyecto que se les proporciona. Para ello se utilizar´ an 2 sesiones te´ oricas y 1 de problemas. En esta lecci´ on no hay sesi´ on de seguimieto de proyecto porque los alumnos a´ un no han comenzado a realizar ninguno. Contenido: 1.1. Informaci´ on de coordinaci´ on: aulas, profesores, horarios, etc. 1.2. Syllabus: contexto, objetivos, metodolog´ ıa y evaluaci´ on de la asignatura. 1.3. Definiciones de Ingenier´ ıa del Software: ingeniero software, sistema de informaci´ on web, tecnolog´ ıas. 1.4. Entorno de trabajo: workbench, plantilla de ((workspace)), y plantilla de proyecto. 1.5. Sistemas de Informaci´ on web: componentes arquitect´ onicos, Interacci´ on entre componentes, y el marco de trabajo. Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: Maven: maven.apache.org/guides/getting-started/index.html Subversive: www.polarion.com/products/svn/subversive Astah: astah.net/resources/documents/astah-basic-operation.pdf Balsamiq: support.balsamiq.com/customer/portal/topics/49503 E. Pencil: pencil.evolus.vn/wiki/devguide/Introduction.html MySQL: dev.mysql.com/doc/ 5.3.2 Lecci´on 2: Modelos de Dominio Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca las herramientas de modelado necesarias para poder comprender y aplicar como se 82 5.3. CONTENIDOS DE LA ASIGNATURA elabora un modelo conceptual a partir de una especificaci´ on informal de requisitos, un modelo de dominio UML a partir del modelo conceptual y un modelo de dominio en Java a partir del modelo de dominio UML. Para ello se utilizar´ an 1 sesi´ on te´ orica, 2 de problemas y 1 de seguimiento del proyecto. Contenido: 2.1. Modelos Conceptuales: concepto y dise˜ no con UML. 2.2. Modelos de Dominio UML: Conceptos, relaciones, restricciones, etc. 2.3. Limpieza de los modelos: evitar duplicidad y mejoras de legibilidad. 2.4. Modelos de Dominio Java: Conversi´ on de Modelos de Dominio UML a modelos de dominio Java. Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: Systems analysis design UML version 2.0. Alan Dennis, Barbara Haley Wixom, David Tegarden. J. Wiley & Sons, 2012. Systems design with Java, UML and MDA. Kevin Lano. Elsevier Butterworth- Heinemann, 2005. Para consultas sobre las anotaciones en Java: Java 7 Programming. Poornachandra Sarang. McGraw-Hill, 2012. 5.3.3 Lecci´on 3: Modelos de Persistencia Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca, comprenda y sea capaz de aplicar persistencia el modelo de dominio en Java, es decir, c´ omo incluir en dicho modelo las anotaciones necesarias para que sus entidades puedan almacenarse en una base de datos y recuperarse a partir de la misma. Para ello se utilizar´ an 1 sesi´ on te´ orica, 2 de problemas y 1 de seguimiento del proyecto. Contenido: 3.1. Conversi´ on de Modelos de Dominio en Modelos de Persistencia con JPA. 3.2. Conceptos para poblar la Base de Datos. 3.3. Herramienta de Consulta a la Base de Datos. 3.4. Conversi´ on de Modelos de Dominio UML a modelos de dominio Java. 83 CAP´ ITULO 5. PROGRAMA DE “DISE ˜ NO Y PRUEBAS” Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: openjpa.apache.org/builds/1.0.2/apache-openjpa-1.0.2/manual/ manual.html. www.objectdb.com/java/jpa/. docs.spring.io/spring-framework/spring-framework-reference/ html/beans.html. Pro JPA 2: Mastering the Java Persistence API. Mike Keith, Merrick Schnicariol. Apress, 2010. Oracle database 11g & MySQL 5.6 developer handbook. Michael McLaughlin. McGraw-Hill, 2012. 5.3.4 Lecci´on 4: Repositorios y Servicios Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca, comprenda y sea cap´ az de aplicar la tecnolog´ ıa que necesitan para poder implementar los repositorios que permiten persistir las entidades del modelo de dominio en una base de datos relacional, as´ ı como una gu´ ıa metodol´ ogica para implementar servicios que hacen uso de los mismos. Para ello se utilizar´ an 1 sesi´ on te´ orica, 2 de problemas y 1 de seguimiento del proyecto. Contenido: 4.1. Repositorios: implementaci´ on con JPA, Consultas a medida, Configuraci´ on del Proyecto. 4.2. Servicios: Estructura, Reglas de negocio, Transacionalidad, Configuraci´ on del Proyecto. 4.3. Comprobando Repositorios y Servicios. Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: Pro Spring MVC: with Web Flow. Marten Deinum, Koen Serneels, Colin Yates, Seth Ladd, and Christophe Vanfleteren. Springer, 2012. docs.spring.io/spring/docs/spring-framework-reference. 84 5.3. CONTENIDOS DE LA ASIGNATURA 5.3.5 Lecci´on 5: Vistas Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca, comprenda y aplique la tecnolog´ ıa necesaria para implementar interfaces de usuario mediante las que implementar los casos de uso descritos en los requisitos. Para ello se utilizar´ an 1 sesi´ on te´ orica, 2 de problemas y 1 de seguimiento del proyecto. Contenido: 5.1. P´ agina Maestra: dise˜ nos comunes, Tecnolog´ ıa ((Apache tiles)). 5.2. Desarrollando las Vistas: dise˜ nos comunes, Tecnolog´ ıa ((JSP)). 5.3. Configuraci´ on del Proyecto: Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: GUI bloopers 2.0: common user interface design don’t and dos. Jeff Johnson. Morgan Kaufmann, 2008. 5.3.6 Lecci´on 6: Controladores Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca, caomprenda y aplique un conjunto de plantillas que les permiten implementar los casos de uso t´ ıpicos de listado, creaci´ on, modificaci´ on o borrado de entidades. Para ello se utilizar´ an 1 sesi´ on te´ orica, 1 de problemas y 4 de seguimiento del proyecto. Contenido: 6.1. Convertidores. 6.2. Estructura de un Controlador. 6.3. Controladores de Listado. 6.4. Controladores de Edici´ on. 6.5. Configuraci´ on del proyecto. Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: GUI bloopers 2.0: common user interface design don’t and dos. Jeff Johnson. Morgan Kaufmann, 2008. 85 CAP´ ITULO 5. PROGRAMA DE “DISE ˜ NO Y PRUEBAS” 5.3.7 Lecci´on 7: Despliegue Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca, comprenda y aplique el despliegue de la base de datos y la aplicaci´ on que compone un sistema de informaci´ on web. Para ello se utilizar´ an 1 sesi´ on te´ orica, 1 de problemas y 4 de seguimiento del proyecto. Contenido: 7.1. Configuraciones. 7.2. Configuraci´ on de Desarrollo. 7.3. Configuraci´ on de Pre-Producci´ on. 7.4. Configuraci´ on de Producci´ on. 7.5. Despliegue de la Base de Datos. 7.6. Despliegue de la Aplicaci´ on. Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: MySQL, 5th edition. P. DuBois. Addison-Wesley, 2013. Apache Tomcat 7 essentials. Tanuj Khare. Packt Publishing, 2012. 5.3.8 Lecci´on 8: Lecciones Aprendidas Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca y comprenda las leyes que afectan a los sistemas de informaci´ on web; la gesti´ on de los proyectos correspondientes a cada entregable; la documentaci´ on de los proyectos; el dise˜ no de las vistas; la eficiencia de las consultas sobre la base de datos; y la prevenci´ on del hacking. Esto se hace mediante una recapitulaci´ on sobre qu´ e se ha hecho en la asignatura durante el primer cuatrimestre y se concluye que tenemos que mejorar en todos esos aspectos. Para ello se utilizar´ an 2 sesiones te´ oricas y 4 de seguimiento del proyecto. Contenido: 86 5.3. CONTENIDOS DE LA ASIGNATURA 8.1. Leyes que afectan a los sistemas de informaci´ on web. 8.2. Gesti´ on de proyectos de desarrollo de sistemas de informaci´ on web. 8.3. Documentaci´ on ´ agil en desarrollo de sistemas de informaci´ on web. 8.4. Mejora del dise˜ no de Vistas. 8.5. Eficiencia en Consultas a la Base de Datos. 8.6. Prevenci´ on del Hacking. Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: European acts: europa.eu/eu-law/decision-making/legal-acts/index_ en.htm. LSSI: www.lssi.gob.es/paginas/Index.aspx. Repository: www.clear.rice.edu/comp314/svn.html. JSP custom tags: docs.oracle.com/javaee/5/tutorial/doc/bnalj.html. Hacking web apps. Mike Shema. Syngress, 2012. ISBN: 9781597499569. 5.3.9 Lecci´on 9: Pruebas Funcionales Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca, comprenda y aplique una gu´ ıa sencilla para que puedan desarrollar casos de prueba a partir de los requisitos del sistema. Para ello se utilizar´ an 1 sesi´ on te´ orica, y 7 de seguimiento del proyecto. Contenido: 9.1. Teor´ ıa sobre Pruebas Funcionales. 9.2. Entorno de trabajo de pruebas funcionales: JUnit. 9.3. Metodolog´ ıa para pruebas funcionales. Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: JUnit recipes: practical methods for programmer testing. Joe B. Rainsberger. Manning, 2005. 87 CAP´ ITULO 5. PROGRAMA DE “DISE ˜ NO Y PRUEBAS” 5.3.10 Lecci´on 10: Pruebas de Rendimiento Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca, comprenda y aplique algunas t´ ecnicas b´ asicas para analizar el rendimiento de un sistema. Para ello se utilizar´ an 1 sesi´ on te´ orica, y 3 de seguimiento del proyecto. Contenido: 10.1. Teor´ ıa sobre Pruebas de Rendimiento. 10.2. Herramienta para probar el Rendimiento: JMeter. 10.3. Fundamentos de la Diagnosis de sistemas de informaci´ on web. Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: Performance Testing With JMeter 2.9. Bayo Erinle. Packt Publishing, 2013. jmeter.apache.org/. https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html. www.restapitutorial.com/httpstatuscodes.html. 5.3.11 Lecci´on 11: Pruebas de Aceptaci´on Objetivos docentes espec´ıficos: En esta lecci´ on se pretende que el alumno conozca, comprenda y aplique los conocimientos necesarios para realizar una validaci´ on como usuario de un sistema. Para ello se utilizar´ an 1 sesi´ on te´ orica, y 3 de seguimiento del proyecto. Contenido: 11.1. Plantillas para las Pruebas de Aceptaci´ on. 11.2. Gu´ ıas para aceptar vistas de listado. 11.3. Gu´ ıas para aceptar vistas de edici´ on. Bibliograf´ıa de consulta: Adem´ as de la bibliograf´ ıa del apartado §5.5, se recomienda: Bridging the communication gap: specification by example and agile acceptance testing. Gojko Adzic. London : Neuri, 2009. 88 5.4. ACTIVIDADES FORMATIVAS 5.3.12 Lecci´on 12: Hackathon Objetivos docentes espec´ıficos: La ´ ultima lecci´ on es un hackathon en el que, b´ asicamente, se deja al alumno que dise˜ ne su propio proyecto; son ellos quienes deciden la tem´ atica y los requisitos que van a implementar. El papel de los profesores es tan s´ olo garantizar que el proyecto est´ a alineado con los objetivos de la asignatura, tiene una carga de trabajo razonable y supervisar el desarrollo del proyecto. Para ello s´ olo se hace uso de 7 sesiones de seguimiento de proyecto. 5.4 ACTIVIDADES FORMATIVAS Las actividades formativas que se proponen son: clases te´ oricas (docencia te´ orica en aula), clases pr´ acticas en aula (actividad pr´ actica en aula orientada a la aplicaci´ on de conocimientos a situaciones concretas como estudio de casos o resoluci´ on de problemas), y clases de seguimiento del proyecto de los alumnos que podr´ ıan englobarse en las pr´ acticas de laboratorios (actividades desarrolladas en espacios con equipamiento especializado). Cada una de las clases mencionadas ser´ an impartidas en dos horas continuadas. A continuaci´ on se indican las horas presenciales, junto con la metodolog´ ıa de ense˜ nanza y aprendizaje para cada una de ellas. Clases te´oricas: 26 horas presenciales y 20 horas no presenciales. • Se realizar´ an presentaciones te´ oricas de las lecciones de la asignatura, en alg´ un caso, con peque˜ nos problemas asociados a los mismos. • Al comienzo de cada sesi´ on te´ orica, se suministra a los estudiantes el siguiente material: 1. Transparencias que se usar´ an en cada una de las sesiones de trabajo correspondientes a esa lecci´ on. 2. C´ odigo fuente, modelos, scripts y otros artefactos que pueden servir de apoyo a los estudiantes. 3. Descripci´ on del entregable asociado con esa lecci´ on, incluyendo criterios de aceptaci´ on del mismo. 89 CAP´ ITULO 5. PROGRAMA DE “DISE ˜ NO Y PRUEBAS” La calificaci´ on en las dos convocatorias extraordinarias (septiembre y diciembre) vienen dado por los siguientes ep´ ıgrafes: Se publicar´ an los enunciados de seis entregables que los estudiantes deber´ an realizar. Dichos entregables tendr´ an unos requisitos y requerir´ an un esfuerzo similar al requerido por los proyectos desarrollados en la convocatoria ordinaria (junio). Los seis entregables tendr´ an que ser realizados por el mismo grupo de estudiantes. Para aprobar la asignatura, un estudiante tiene que aprobar todos los entregables y el control, que versar´ a sobre uno de los proyectos desarrollados en los entregables. En ese caso, su calificaci´ on ser´ a la media de las calificaciones obtenidas en los entregables. 96 6 PROGRAMA DE INGENIER´ IA DEL SOFTWARE Y PR´ ACTICA PROFESIONAL 97 6.1 CONSIDERACIONES GENERALES En el Proyecto Docente e Investigador se ha presentado la relaci´ on de asignaturas que conforman el perfil de la plaza. Corresponde a este cap´ ıtulo perfilar y desarrollar el contenido de la asignatura “Ingenier´ ıa del Software y Pr´ actica Profesional”. Para ello, nos proponemos presentar un programa completo que recoge los distintos condicionantes que se han analizado en dicho proyecto. Conviene recordar los condicionantes temporales y de audiencia de la asignatura antes de realizar el desarrollo de la misma: se trata de una asignatura obligatoria del segundo cuatrimestre del cuarto y ´ ultimo curso del Grado en Ingenier´ ıa Inform´ atica- Ingenier´ ıa del Software que tiene asignada una carga lectiva de 6 ECTS que se imparten a un grupo “grande” (80-120 alumnos). El resto del cap´ ıtulo mantiene la estructura y recomendaciones de estilo de “Proyecto Docente” que fija la actual normativa de la Universidad de Sevilla, para la cual el concepto de “Programa Docente” se reserva para una versi´ on m´ as reducida y general que idealmente debe tener una vigencia cercana a la del Plan de Estudios. En este sentido creemos oportuno se˜ nalar que ni el Proyecto ni el Programa Docente exige indicar las recomendaciones sobre los conocimientos m´ ınimos que se debieran tener, ni las asignaturas recomendadas cursar al mismo tiempo. 6.2 OBJETIVOS Y COMPETENCIAS Objetivos docentes espec´ıficos: El objetivo de esta materia es que el alumno conozca, compranda y sepa como desarrollar sistemas de informaci´ on web en un contexto profesional. CAP´ ITULO 6. INGENIER´ IA DEL SOFTWARE Y PR ´ ACTICA PROFESIONAL En general, el grado en que se encuentra esta asignatura tiene una marcada orientaci´ on hacia el desarrollo de sistemas de informaci´ on web, que es en nuestro entorno local una de las principales fuentes de ofertas de trabajo para nuestros estudiantes. El objetivo de la asignatura se encuentra por lo tanto perfectamente alineado con este sesgo del grado. Concretamente, en esta asignatura se desarrollan dos competencias gen´ ericas y tres competencias espec´ ıficas que se enumeran a continuaci´ on. Competencias transversales/gen´ericas: G01. Capacidad para concebir, redactar, organizar, planificar, desarrollar y firmar proyectos en el ´ ambito de la ingenier´ ıa en inform´ atica que tengan por objeto, de acuerdo con los conocimientos adquiridos, la concepci´ on, el desarrollo o la explotaci´ on de sistemas, servicios y aplicaciones inform´ aticas. G02. Capacidad para dirigir las actividades objeto de los proyectos del ´ ambito de la inform´ atica. Competencias espec´ıficas: E26. Capacidad para valorar las necesidades del cliente y especificar los requisitos software para satisfacer estas necesidades, reconciliando objetivos en conflicto mediante la b´ usqueda de compromisos aceptables dentro de las limitaciones derivadas del coste, del tiempo, de la existencia de sistemas ya desarrollados y de las propias organizaciones. E29. Capacidad de identificar, evaluar y gestionar los riesgos potenciales asociados que pudieran presentarse. E30. Capacidad para dise˜ nar soluciones apropiadas en uno o m´ as dominios de aplicaci´ on utilizando m´ etodos de la ingenier´ ıa del software que integren aspectos ´ eticos, sociales, legales y econ´ omicos. 6.3 CONTENIDOS DE LA ASIGNATURA La asignatura est´ a estructurada en 5 fases como se muestra en la tabla §6.1. Cada fase tendr´ a una duraci´ on acorde a su complejidad y se desarrollan mediante un ´ unico 98 6.3. CONTENIDOS DE LA ASIGNATURA Cuatrimeste Fase T´ıtulo Horas 1Calentamiento 4 2Dise˜ no del Proyecto 12 23Desarrollo del Proyecto 24 4Presentaci´ on del Proyecto 8 5Desarrollo del Plan de Negocio 12 Total 60 Cuadro 6.1: Relaci´ on detallada y ordenaci´ on temporal de contenidos tipo de actividad formativa presencial que se pueden englobar en las denominadas clases de seminario (sesiones monogr´ aficas supervisadas por el profesorado). Cada fase de la asignatura comprende de dos a seis clases de seminario en las que los estudiantes presentan el avance del trabajo desarrollado por su grupo y reciben comentarios de los prefosores sobre aquellos aspectos que deben mejorar para hacer su trabajo m´ as cercano al mundo profesional. Dichas fases ser´ an evaluada al t´ ermino de las mismas con una exposici´ on en clase y un entregable que los estudiantes tendr´ an que realizar como integrantes de un grupo de trabajo. La calificaci´ on de los estudiantes depender´ a del grado de asimilaci´ on del feedback tanto positivo como negativo aportado por los profesores a todos los grupos y no solo al que pertenencen. 6.3.1 Fase 1: Calentamiento Objetivos docentes espec´ıficos: En esta fase se presenta la asignatura, la mec´ anica de trabajo mediante el planteamiento de un reto que deben resolver los estudiantes solos y como quieran, se presentan los profesores como se espera en un contexto profesional y se invita a alg´ un estudiante a que se presente, y finalmente se espera que los estudiantes se re´ unan en grupos y decidan un proyecto a realizar. Contenido: 1.1. Reto a resolver a modo de ((examen)): para analizar c´ omo se han organizado. 1.2. Presentaci´ on en un contexto profesional. 1.3. Informaci´ on de coordinaci´ on: aulas, profesores, horarios, etc. 1.4. Syllabus: contexto, objetivos, metodolog´ ıa y evaluaci´ on de la asignatura. 1.5. Elecci´ on de grupos y tem´ atica del proyecto. 99 CAP´ ITULO 6. INGENIER´ IA DEL SOFTWARE Y PR ´ ACTICA PROFESIONAL 6.3.2 Fase 2: Dise˜no del Proyecto Objetivos docentes espec´ıficos: En esta fase se espera que los grupos de estudiantes sean capaces de demostrar que su proyecto tiene caracter´ ısticas propias de proyectos reales de un contexto profesional como son la viabilidad econ´ omica, desarrollo factible, modelo de negocio realista, etc. 2.1. Desarrollo de un pan de negocio inicial: modelo de negocio, roles de usuarios y clientes, an´ alisis DAFO, estudio de la competencia, etc. 2.2. Desarrollo de perfiles concretos en equipos de desarrollo: Portavoz, Gestor de Proyecto, Analista, etc. 2.3. Presentaci´ on ((no-t´ ecnica)) del proyecto ante la clase para recibir feedback. 2.4. Comprobaci´ on de la gesti´ on del conocimiento. 6.3.3 Fase 3: Desarrollo del Proyecto Objetivos docentes espec´ıficos: En esta fase se espera que los estudiantes aprendan las dificultades que tiene dividir un proyecto en Sprints para ser desarrollados mediante metodolog´ ıas ´ agiles y aprendan a gestionar las distintas tareas de an´ alisis y desarrollo del proyecto. Contenido: 3.1. Implementaci´ on y pruebas del proyecto profesional elegido por cada grupo. 3.2. Presentaci´ on ((t´ ecnica)) del proyecto ante la clase para recibir feedback: resumen de la idea del proyecto, equipo de trabajo, tareas desarrolladas y por desarrollar, demo de lo desarrollado, planificaci´ on de la siguiente semana, lecciones aprendidas, etc. 3.3. Conceptos pr´ acticos de una exposici´ on profesional. 3.4. Conceptos de organizaci´ on del trabajo. 3.5. Conceptos de planes de contigencia. 3.6. Conceptos sobre c´ omo presentar una demo. 3.7. Comprobaci´ on de la gesti´ on del conocimiento. 100 6.3. CONTENIDOS DE LA ASIGNATURA 6.3.4 Fase 4: Presentaci´on del Proyecto Objetivos docentes espec´ıficos: En esta fase se ense˜ na a los estudiantes c´ omo presentar el proyecto ante grupos externos de inversores o interesados en el mismo. Contenido: 4.1. Conceptos b´ asicos en una presentaci´ on de proyecto profesional: sencillez, atractivo, etc. 4.2. Realizaci´ on de videos promocionales dirigidos a roles espec´ ıficos: usuarios, o clientes, o usuarios-clientes. 4.3. Comprobaci´ on de la gesti´ on del conocimiento. 6.3.5 Fase 5: Desarrollo del Plan de Negocio Objetivos docentes espec´ıficos: En esta fase se ense˜ na a los estudiantes los aspectos fundamentales de un plan de negocio din´ amico que deben conocer y saber exponer en un contexto profesional. Contenido: 5.1. Caracter´ ısticas fundamentales del Plan de Negocio en nuestro contexto: sencillo, din´ amico, a corto-medio plazo, centrado en el cliente, considerando la competencia. 5.2. Conceptos b´ asicos sobre c´ omo presentar el producto o servicio. 5.3. Conceptos b´ asicos sobre un estudio de mercado: segmentaci´ on de usuarios y clientes. 5.4. Conceptos b´ asicos sobre el plan de marketing: alternativas de comunicaci´ on hacia los usuarios y clientes. 5.5. Conceptos b´ asicos sobre el estudio de la competencia. 5.6. Conceptos b´ asicos sobre c´ omo presentar un presupuesto. 5.7. Conceptos b´ asicos sobre c´ omo presentar beneficios. 5.8. C´ omo estructurar un CV y una carta de presentaci´ on de manera efectiva. 5.9. C´ omo afrontar una entrevista de trabajo de manera efectiva. 101 CAP´ ITULO 6. INGENIER´ IA DEL SOFTWARE Y PR ´ ACTICA PROFESIONAL 6.4 ACTIVIDADES FORMATIVAS Las ´ unica actividad formativa que se propone es el uso de clases de seminario (sesiones monogr´ aficas supervisadas por el profesorado) en sesiones cont´ ınuas de cuatro horas. Clases de seminario: 60 horas presenciales y 90 horas no presenciales. • Cada grupo de alumno presentar´ a el avance del trabajo de su grupo de la forma m´ as adecuada que se les ocurra, dependiendo de la fase de la asignatura en la que se est´ e. • Al termino de cada presentaci´ on tanto el resto de compa˜ neros como los profesores pueden hacer preguntas y dar feedback a los estudiantes tanto positivo como negativo sobre el contenido que acaban de exponer. • En caso de no ser la primera presentaci´ on, adem´ as se podr´ a hacer referencia a feedback previo dado en clase para preguntar a los estudiantes que acaban de presentar los motivos de atender a dicho feedback o no en su presentaci´ on actual. En esta asignatura no existe una bibliograf´ ıa de referencia puesto que el contenido real de las fases depende de los propios estudiante. 6.5 SISTEMAS Y CRITERIOS DE EVALUACI ´ ON Y CALIFICACI ´ ON 6.5.1 Sistema de evaluaci´on Tal y como establece el art´ ıculo 6 de la normativa de la Universidad de Sevilla que regula la evaluaci´ on y calificaci´ on de las asignaturas, la evaluaci´ on de las competencias, conocimientos y capacidades adquiridas por los estudiantes podr´ an basarse en actividades de evaluaci´ on continua, ex´ amenes parciales y/o ex´ amenes finales. La asistencia a clases te´ oricas podr´ a puntuar de manera positiva en la calificaci´ on final. Adem´ as se podr´ an contemplar requisitos espec´ ıficos, que deber´ an ser definidos en los proyectos docentes anuales, en relaci´ on a la realizaci´ on de ex´ amenes, a la realizaci´ on 102 6.5. SISTEMAS Y CRITERIOS DE EVALUACI ´ ON Y CALIFICACI ´ ON de cualquier otro tipo de pruebas, a la obligatoriedad en la realizaci´ on de trabajos, a la obligatoriedad a la asistencia a clases pr´ acticas, a proyectos y a clases pr´ acticas de laboratorio, as´ ı como a la participaci´ on en seminarios. Para esta asignatura no se establece ning´ un requisito espec´ ıfico y se proponen las siguientes actividades de evaluaci´ on: Presentaciones en clase: • Cada grupo podr´ a tener un portavoz fijo o no, seg´ un decidan. • Podr´ an usar los materiales y herramientas que quieran para hacer la presentaci´ on: ca˜ n´ on, port´ atil, etc´ etera. • Podr´ an tomar las decisiones que estimen para presentar su trabajo. Entregables que se realizan en grupo. Aspectos a destacar sobre los entregables: • El tama˜ no m´ ınimo y m´ aximo de integrantes de los grupos lo deciden los alumnos pero se fomenta que el n´ umero m´ ınimo sea de 4-5 personas para que tengan que resolver problemas de coordinaci´ on y gesti´ on interna. • Los propios estudiantes deciden, de manera coordinada con los profesores el contenido que debe tener cada uno de los entregables. • Lo entregables se corresponden con la ´ ultima presentaci´ on hecha en clase antes de la fecha del entregable. • En las fases de la asignatura que as´ ı lo requieran, los entregables tambi´ en incluir´ an una url para probar el estado actual del proyecto que est´ a siendo desarrollado por los alumnos. • Al obtener el feedback en su presentaci´ on ya se les informa de qu´ e calificaci´ on han obtenido aport´ andoles los motivos de dicha decisi´ on. Los entregables ser´ an evaluados como A+ (”Sobresaliente 10 con opci´ on a Matr´ ıcula de Honor”), A (”Sobresaliente 9”), B (”Notable 8” o “Notable 7”), C (.Aprobado 6” o “Aprobado 5”). Un entregable que no contempla los requisitos de nivel C se considerar´ a F (”Suspenso 4” o ”Suspenso 0”). • La nota de cada entregable depender´ a del nivel de profesionalidad alcanzado en cada entrega y de la capacidad de los grupos de estudiantes de hacer 103 CAP´ ITULO 6. INGENIER´ IA DEL SOFTWARE Y PR ´ ACTICA PROFESIONAL frente al feedback potivo y negativo aportado por los profesores para todos y cada uno de los grupos de estudiantes, no s´ olo del feedback que un grupo espec´ ıfico reciba. • El n´ umero de A+’s ser´ a regulado por la legislaci´ on aplicable a la asignatura. 6.5.2 Criterios de calificaci´on La asistencia a clases de seminario no punt´ ua en la calificaci´ on final y se eval´ ua sobre todo la capacidad de los alumnos para recibir feedback, tanto positivo como negativo. En este caso adem´ as se permite que dicho feedback provenga tanto de los alumnos como de los profesores. Adem´ as dicho feedback puede ser de muy diversa ´ ındole, como se ve en las fases de la asignatura, ya que puede referirse tanto a contenido como a forma, e incluso puede darse feedback sobre comportamientos actitudinales que sean relevantes en la pr´ actica profesional. Finalmente la calificaci´ on obtenida por un grupo de estudiantes s´ olo podr´ a ser A (Sobresaliente), A+ (Sobresaliente con opci´ on a matr´ ıcula de honor) o F (Suspenso). Esto es debido a que en un entorno profesional lo que prima es que los proyectos salgan adelante con el nivel m´ aximo. Es decir no se admite un proyecto con nota intermedia. Dicha nota final tendr´ a en cuenta las notas obtenidas en cada entregable. 104 BIBLIOGRAF´ IA 105 [1] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison- Wesley Professional, 3rd edition, 2012. ISBN 0321815734, 9780321815736. [2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern- Oriented Software Architecture - Volume 1: A System of Patterns. Wiley Publishing, 1996. ISBN 0471958697, 9780471958697. [3] J. Cheesman and J. Daniels. UML Components: A Simple Process for Specifying Component-based Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2000. ISBN 0-201-70851-5. [4] R. Daigneau. Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services. Addison-Wesley Professional, 1 edition, 2011. ISBN 032154420X, 9780321544209. [5] P. Eeles and P. Cripps. The Process of Software Architecting. Addison-Wesley Professional, 2010. ISBN 0321357485. [6] G. Hohpe and B. Woolf. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. ISBN 0321200683. [7] M. Masse. REST API design rulebook. O’Reilly Media, 2011. [8] G. J. Myers and C. Sandler. The Art of Software Testing. John Wiley & Sons, 2004. ISBN 0471469122. [9] D. Pilone and N. Pitman. Uml 2.0 in a Nutshell. O’Reilly Media, Inc., 1 edition, 2005. ISBN 978-0-596-00795-9. [10] R. S. Pressman. Ingenier´ıa del Software. Un Enfoque Pr´actico. McGraw–Hill, 5ª edition, 2001. AP´ ENDICE B. INSTITUTO UNIVERSITARIO EN INGENIER´ IA INFORM ´ ATICA B.1 CONTEXTO Las primeras titulaciones en Inform´ atica en la Universidad de Sevilla se pusieron en marcha en el curso 1985/86, consolid´ andose sus primeros Grupos de Investigaci´ on en el curso 1996/97 tras la aprobaci´ on de los primeros t´ ıtulos de Ingenier´ ıa Inform´ atica. En el a˜ no 2000 se crea la Fundaci´ on para la Investigaci´ on y el Desarrollo de las Tecnolog´ ıas de la Informaci´ on en Andaluc´ ıa (FIDETIA), y en el 2001 la Escuela T´ ecnica Superior de Ingenier´ ıa Inform´ atica (ETSII). Actualmente, la ETSII oferta tres Grados en Ingenier´ ıa Inform´ atica, que cubren ´ areas como Tecnolog´ ıas y Sistemas de la Informaci´ on, Computaci´ on, Ingenier´ ıa del Software, Ingenier´ ıa de Computadores y Redes de Datos; cuatro M´ aster oficiales, incluyendo un nuevo M´ aster que capacita para el ejercicio de la profesi´ on de Ingeniero Inform´ atico; y un Programa de Doctorado en Ingenier´ ıa Inform´ atica. En el marco del Campus de Excelencia “Andaluc´ ıa Tech”, se oferta tambi´ en un Grado en Ingenier´ ıa de la Salud, grado conjunto con la Universidad de M´ alaga. Puede afirmarse que tras m´ as de 25 a˜ nos de andadura, los estudios de Inform´ atica en la Universidad de Sevilla han alcanzado su madurez. Los Grupos de Investigaci´ on de la ETSII mantienen una intensa actividad que se traduce en numerosos proyectos competitivos nacionales e internacionales, contratos con empresas y administraciones, creaci´ on de empresas de base tecnol´ ogica, etc. Un indicador del reconocimiento de la buena marcha de esta actividad lo ofrece el Ranking de la Universidad Nacional de Taiw´ an (NTU), donde la Universidad de Sevilla ocupa en 2014 el puesto 182 a nivel mundial en el que en el campo de la Inform´ atica, escalando casi 50 puestos desde la posici´ on 228 ocupada en 2013. B.2 POR QU ´ E UN INSTITUTO La propuesta en el a˜ no 2014 del programa de doctorado “Ingenier´ ıa Inform´ atica” que incorpora las l´ ıneas de los investigadores de referencia de la ETSII ha conseguido aumentar entre sus miembros la conciencia de ’supergrupo’ de investigaci´ on y generado un sentimiento de investigaci´ on en Ingenier´ ıa Inform´ atica. Por otra parte, teniendo FIDETIA una infraestructura probada para transferir co- 112 B.2. POR QU´ E UN INSTITUTO nocimiento, y en el programa de doctorado de la ETSII una fuente de j´ ovenes investigadores, es el momento de generar un instrumento espec´ ıfico de generaci´ on de conocimiento cient´ ıfico y tecnol´ ogico que complete a los actuales instrumentos espec´ ıficos de docencia (ETSII) y de transferencia (FIDETIA): el I3US. Si bien los miembros del I3US podr´ an seguir siendo miembros de los equipos de trabajo de FIDETIA, la idea es diferenciar la actividad de investigaci´ on de la de transferencia, aunque con un canal que permita una transmisi´ on fluida. De hecho, se propone que un representante de la ETSII y un representante de FIDETIA formen parte de su Comisi´ on Asesora. El I3US debe ayudar a conseguir nuevas ambiciones que trascienden a investigadores y grupos, a saber: Complementar la simbiosis ETSII-FIDETIA. El I3US surge con vocaci´ on de complementar la simbiosis existente entre la ETSII y FIDETIA, en adelante Sistema ETSII-FIDETIA. FIDETIA se ha visto como un instrumento eficaz y exitoso para transferir resultados de grupos de manera individual, y para facilitar la gesti´ on de iniciativas de muy diversa ´ ındole: pr´ actica en empresa, proyectos de consultor´ ıa, contratos de I+D, proyectos de investigaci´ on, etc. Estas actividades se han realizado siempre en consonancia a las intereses de la ETSII, no en vano, el director de la ETSII es el Presidente de FIDETIA. Definici´ on e implantaci´ on de pol´ ıticas de investigaci´ on. El I3US debe proporcionar directrices encaminadas a conseguir nuevas metas que trasciendan a investigadores y grupos, por lo que debe tener capacidad para definir objetivos estrat´ egicos y para lograr su consecuci´ on. Ser´ ıa deseable contar con una agenda estrat´ egica de investigaci´ on equilibrada que empuje a generar resultados de investigaci´ on b´ asica y a aplicar dichos resultados, o resultados ajenos, a resolver retos de la sociedad. Fomentar la interdisciplinaridad. Las estructuras actuales de la US no est´ an dise˜ nadas para favorecer la interdisciplinaridad, aspecto clave para obtener el m´ aximo beneficio y rentabilidad de las potenciales sinergias que pueden darse entre los investigadores en Ingenier´ ıa Inform´ atica. Ser´ a objetivo del I3US potenciar la capacidad individual de sus investigadores potenciando la capacidad colectiva 113 AP´ ENDICE B. INSTITUTO UNIVERSITARIO EN INGENIER´ IA INFORM ´ ATICA del instituto y de sus grupos de investigaci´ on participantes. Este objetivo podr´ ıa y deber´ ıa ser ampliable con los restantes Institutos de Investigaci´ on de la Universidad de Sevilla. Estamos seguros que esta apertura ayudar´ a a plantear necesidades y aportar soluciones entre Institutos. Mejorar la gesti´ on de RRHH. La capacitaci´ on, entrenamiento, evaluaci´ on del rendimiento y la definici´ on de responsabilidades de los miembros del I3US, junto con la selecci´ on de j´ ovenes investigadores y la formaci´ on de lideres, son actividades clave para que el instituto consiga sus objetivos, y para las que la US no ofrece instrumentos eficaces. Gestionar estas actividades es costoso y resulta rentable a partir de un cierto tama˜ no. Ser´ ıa deseable disponer de un modelo de mejora continua del funcionamiento del Instituto y un proceso selectivo ´ agil y eficaz para seleccionar personal en general y beneficiarios de becas en particular. Investigaci´ on como servicio. Una parte importante de los resultados que hasta la fecha han obtenido los promotores del instituto y de los que se prev´ e obtener en el futuro, son susceptibles de ser gestionado siguiendo una filosof´ ıa ”XaaS”(Everything as a Service). Este modelo fuerza a definir un interfaz de uso pensada para ser consumida y facturada de manera c´ omoda e intuitiva. Estamos convencidos de que esta aproximaci´ on facilitar´ a el uso efectivo de los resultados del instituto. Del mismo modo, estamos convencidos que para alcanzar este objetivo en poco tiempo es importante interiorizarlo y promocionarlo desde la direcci´ on del I3US, y que para que suponga ingresos significativos debe intentarse aplicar en todas sus l´ ıneas, pues en todas es potencialmente susceptible servitizar sus resultados. Ser´ ıa deseable disponer en un corto plazo un repositorio de los resultados “listos para ser usados” no s´ olo con prop´ ositos de difusi´ on, y compartici´ on de conocimiento, sino tambi´ en de obtenci´ on de ingresos. El I3US tambi´ en puede ayudar a consolidar algunos logros ya conseguidos, a saber: Internacionalizaci´ on. El grado de internacionalizaci´ on obtenido por el Sistema ETSII-FIDETIA ha experimentado un impulso importante, prueba de ello es la mejora en r´ anquines internacionales. El I3US ser´ a un elemento clave para reforzar la estrategia de internacionalizaci´ on del sistema ETSII-FIDETIA en la triple 114 B.2. POR QU´ E UN INSTITUTO dimensi´ on: docente, investigadora y de transferencia. Ser´ a de vital importancia conseguir una coordinaci´ on ´ agil, eficaz y eficiente entre ETSII-FIDETIA-I3US para conseguir este objetivo, siendo un compromiso adquirido por los promotores del I3US no s´ olo respetar los actuales espacios de responsabilidad de la ETSII y de FIDETIA, sino ayudar en la medida de lo posible a que se afiancen y mejoren. Competitividad del tejido empresarial y de las AAPP. La incorporaci´ on de tecn´ ologos y doctores a empresas y a Administraciones P´ ublicas (AAPP) se ha incrementado en los ´ ultimos a˜ nos por el aumento de doctores y tecn´ ologos que no han podido incorporarse a su mercado natural hasta la fecha: OPIs y Centros Tecnol´ ogicos. El I3US tendr´ a muy en cuenta en la definici´ on de su agenda estrat´ egica de investigaci´ on el imperativo de aumentar la competitividad del tejido empresarial y de las AAPP m´ as cercanas. Valor de la Inform´ atica. El empuje que supondr´ a el I3US a mejorar el desarrollo de la Ingenier´ ıa Inform´ atica en su triple perspectiva: investigaci´ on, docencia y transferencia, reforzar´ a sin lugar el valor de la Inform´ atica en el ´ ambito de influencia de la Universidad de Sevilla, no s´ olo desde un punto de vista t´ ecnico, sino tambi´ en desde un punto de vista social. Es importante para los promotores avanzar en trasladar a la sociedad el valor important´ ısimo de contar con un centro de Investigaci´ on en un ´ ambito tan cr´ ıtico como es el de las Tecnolog´ ıas de la Informaci´ on y Comunicaciones donde la Inform´ atica desarrolla un papel clave. Generaci´ on de conocimiento. Para transferir conocimiento cient´ ıfico o tecnol´ ogico es necesario que este se genere previamente. Ser´ a objetivo del instituto lograr que se den las condiciones para que sus miembros sigan generando conocimiento pero mejorando su visibilidad internacional y su aplicabilidad. 115 AP´ ENDICE B. INSTITUTO UNIVERSITARIO EN INGENIER´ IA INFORM ´ ATICA 116 View publication stats