La Escuela Iberoamericana de Ingeniería de Software Avanzada (EIbAIS) representa una de las iniciativas de CIbSE para difundir el conocimiento de Ingeniería de Software en Iberoamérica. Esta escuela se ha iniciado como una evolución natural de los tutoriales y cursos cortos de CIbSE, incluyendo temas de vanguardia relacionados no exclusivamente con los principales tracks de CIbSE: tecnologías, experimentación y requisitos.
El objetivo de EIbAIS es promover un foro de discusión sobre la Ingeniería de Software y sus tecnologías y fundamentos teóricos relacionados, permitiendo la participación de profesionales, estudiantes de pregrado y postgrado e investigadores en las actividades de la escuela. Como en cualquier actividad relacionada con CIbSE, todos los profesores son voluntarios comprometidos para contribuir a la comunidad CIbSE y a la difusión del conocimiento de Ingeniería de Software en Iberoamérica.
EIbAIS es organizado en dos categorías básicas de sesiones plenarias durante dos días: módulos sobre el estado de la práctica y módulos sobre el estado del arte. Los módulos sobre el estado de la práctica ofrecen discusiones sobre temas de interés general y generalmente representan la demanda local. Estos módulos complementan los conocimientos sobre cuestiones prácticas de los participantes, presentando a la audiencia resultados de ingeniería de software basados en evidencia. Ejemplos de temas de estado de la práctica incluyen herramientas CASE, pruebas de software de sistemas convencionales, especificaciones basadas en escenarios, encuestas, experimentos controlados, etc.
Los módulos sobre el estado del arte ofrecen discusión sobre temas de interés emergentes y que normalmente representan las perspectivas de la comunidad de Ingeniería de Software. Estos módulos tienen la intención de proporcionar información sobre tecnologías de Ingeniería de Software actuales e innovadores, mostrando los últimos avances en cada tema. Ejemplos de temas del estado del arte incluyen la especificación de requisitos para sistemas ubicuos, pruebas de software de sistemas conscientes del contexto, Ingeniería de Software para Internet de las Cosas, experimentos basados en simulación en Ingeniería de Software, síntesis de la evidencia, etc.
Todos los participantes que asistan a las sesiones plenarias obtendrán un certificado de participación, indicando los módulos, profesores y contenidos. Los temas principales para los dos tipos de módulos de EIbAIS se anunciarán pronto.
Presidentes del comité de programa EIbAIS
- Beatriz Marín (Universidad Politécnica de Valencia, España)
- Efraín Rodrigo Fonseca Carrera (Universidad de las Fuerzas Armadas ESPE, Ecuador)
Charlas de EIbAIS
Carolyn Seaman
Carolyn Seaman es profesora de Sistemas de Información en la Universidad de Maryland Baltimore County (UMBC). También es la directora del Centro de Mujeres en la Tecnología en la UMBC. Su investigación consiste principalmente en estudios empíricos de ingeniería de software, con especial énfasis en el mantenimiento, la estructura organizativa, la comunicación, la medición y la deuda técnica. También investiga los métodos de investigación cualitativa en la ingeniería de software, así como la pedagogía informática. Es doctora en Ciencias de la Computación por la Universidad de Maryland, College Park, tiene un máster de Georgia Tech y un bachillerato del College of Wooster (Ohio).
Decision Making in Software Engineering: The Central Role of Technical Debt
Descripción
La deuda técnica es una metáfora que capta el balance habitual que se produce en los proyectos de desarrollo de software entre las presiones a corto plazo (por ejemplo, el tiempo de entrega) y las preocupaciones a largo plazo (por ejemplo, la capacidad de mantenimiento). Se refiere a los problemas existentes en un producto de software que se generaron ante una presión a corto plazo, pero que suponen un riesgo para la capacidad del equipo de mantener el producto a lo largo del tiempo. Los tipos más comunes de deuda técnica son un código demasiado complejo, un código mal estructurado, un código no documentado, la degradación de la arquitectura del software, pruebas insuficientes, etc. Las decisiones sobre si incurrir en deuda, o cuándo pagarla, o qué deuda pagar, encapsulan perfectamente las disyuntivas a corto vs. largo plazo que son típicas en la ingeniería de software. De hecho, se puede alegar que casi todas las decisiones tomadas durante un proyecto de software están relacionadas de alguna manera con la deuda técnica. Por lo tanto, la comprensión profunda y la mejora en la toma de decisiones sobre la deuda técnica tendrán un impacto significativo en la gestión de los proyectos de software en general. En esta charla, revisaremos las corrientes actuales de investigación sobre la toma de decisiones en materia de deuda técnica, ingeniería del software en general y en las disciplinas relacionadas.
Luis Olsina
Luis Olsina, es Profesor Titular Regular exclusivo en la Facultad de Ingeniería, de la Universidad Nacional de La Pampa, Argentina, Investigador Senior y Director del grupo de I+D denominado GIDIS_Web. Ha recibido los grados de Doctor en Ciencias (Área Ingeniería de Software/Web) y Magister en Ingeniería de Software ambos por la Universidad Nacional de La Plata, Argentina; además de Licenciado en Sistemas de Información y Analista Programador. En los últimos 25 años ha publicado más de 170 artículos científicos en revistas y congresos internacionales y nacionales y, además, ha publicado el libro Web Engineering: Modelling and Implementing Web Applications por Springer, HCIS Series como coeditor junto a sus colegas Rossi, Schwabe y Pastor. Luis ha copresidido eventos científicos como: Web Engineering Workshop celebrado en USA en el marco de ICSE 2002 (Int’l Conference on Software Engineering); los congresos ICWE 2002 y 2003 celebrados en Argentina y España; el workshop IDEAS’04 celebrado en Perú (actualmente CIbSE), además de LA-Web 2005 y 2008 celebradas en Argentina y Brasil, y el Track de Web Engineering de la conferencia WWW’06 celebrada en Edinburgo, UK, entre otros más recientes como QUATIC 2020, en el Track de Requirements Engineering. Sus áreas de mayor interés son Ingeniería de Software/Web, Estrategias, Métodos y Procesos de Medición y Evaluación de Calidad, y Especificación de Ontologías a nivel Fundacional, Core y de Dominio. Ha sido invitado para dictar conferencias, tutoriales y cursos de postgrado del área en diversos países del mundo.
ThingFO: Ontología Fundacional útil para enriquecer diversas terminologías como las de Proceso y Test
Descripción
El objetivo del tutorial consiste en introducir a los participantes en una ontología fundacional de utilidad para todas las ciencias. La misma se denomina ThingFO y se encuentra ubicada en el nivel más alto o fundacional (FO) de una arquitectura ontológica de cuatro capas. El siguiente nivel se denomina core (CO) y aquí se encuentran ubicadas ontologías de Proceso, Situación, Proyecto, entre otras. En ambos niveles mencionados los términos de las ontologías son independientes de cualquier dominio. El nivel siguiente se denomina de dominio (DO) y aquí se encuentran ubicadas ontologías de Test, Evaluación, Requisitos Funcionales y No Funcionales, entre otras. La última capa de la arquitectura se denomina nivel de instancias.
ThingFO representa a un conjunto reducido de términos (Thing, Thing Category y Assertions) que refieren tanto a elementos particulares como universales del mundo y a distintos tipos de afirmaciones sobre los mismos. Estos tres términos (además de las relaciones) son de utilidad para enriquecer términos de las ontologías de proceso (ProcessCO) y de testing (TestTDO), como de cualquier otra. El tutorial ilustrara la utilidad de ThingFO para enriquecer particularmente terminologías de proceso y testing.Tener terminologías explicitas, completas y concisas, ayudan a comunicar y representar de un modo eficaz y eficiente a las especificaciones de estrategias, procesos, métodos y herramientas utilizadas en cualquier ingeniería o ciencia, para resolver problemas de desarrollo, mantenimiento, evaluación y testing.
Oscar Dieste
Oscar Dieste obtuvo su licenciatura y maestría en Informática en la Universidad de La Coruña y su doctorado en la Universidad de Castilla-La Mancha. Es investigador de la Facultad de Ingeniería Informática de la UPM. Anteriormente estuvo en la Universidad de Colorado en Colorado Springs (como becario Fulbright), la Universidad Complutense de Madrid y la Universidad Alfonso X el Sabio. Sus intereses de investigación incluyen la ingeniería de software empírica y la ingeniería de requisitos.
Power analysis made easy
Descripción
El análisis de potencia es una actividad realizada durante el diseño experimental que informa a los experimentadores sobre el tamaño mínimo de muestra para detectar un efecto dado. El tamaño de muestra requerido es un criterio de decisión crucial para saber si la experimentación es valiosa. Si no se puede alcanzar el tamaño mínimo de la muestra, el experimento no dará resultados precisos y podría valer la pena no experimentar en absoluto.
Los experimentos de ingeniería de software (SE) normalmente no incluyen un análisis de potencia. Creo firmemente que los experimentos de SE no consideran inútil el análisis de poder; en su lugar, tienen problemas para realizar este tipo de análisis. Honestamente, yo también. Las herramientas como G*Power son fáciles de usar, pero me siento inseguro cuando informo los resultados.
Sin embargo, el análisis de potencia es relativamente fácil. Este tutorial mostrará cómo crear scripts R para estimar el poder de los modelos lineales (ANOVA, modelos mixtos, etc.) usando métodos Monte-Carlo. Los conceptos se pueden aplicar a enfoques de análisis arbitrarios, por ejemplo, chi-cuadrado, pero cubriremos esa parte solo si tenemos suficiente tiempo. Espero que mis compañeros asistentes informen sobre el análisis de poder en sus artículos en el futuro.