Autor:
Manso, M. Esperanza

Cargando...
Foto de perfil

E-mails conocidos

manso@infor.uva.es

Fecha de nacimiento

Proyectos de investigación

Unidades organizativas

Puesto de trabajo

Apellidos

Manso

Nombre de pila

M. Esperanza

Nombre

Nombres alternativos

Manso, Esperanza

Afiliaciones conocidas

Universidad de Valladolid, Spain
Dpto. Informática, Universidad de Valladolid

Páginas web conocidas

Página completa del ítem
Notificar un error en este autor

Resultados de la búsqueda

Mostrando 1 - 3 de 3
  • Artículo
    Factores que tienen en cuenta los desarrolladores en la priorización de smells para su corrección: conclusiones después de una réplica.
    Alkharabsheh, Khalid; Crespo, Yania; Manso, M. Esperanza; Taboada, José Ángel. Actas de las XXIV Jornadas de Ingeniería del Software y Bases de Datos (JISBD 2019), 2019-09-02.
    La presencia de design smells es uno de los factores que contribuye a aumentar la deuda técnica, es por ello su gestión cobra cada vez más importancia. En este documento se presenta la réplica de un estudio en el que, 10 desarrolladores examinaron issues relacionados con bad smells detectados en un proyecto software con el que no estaban familiarizados, ordenando los que deben modificarse primero, y proporcionando las razones por las que priorizaron así los issues causados por smells. Estas razones sirvieron de base para elaborar un ranking de 13 factores por los que los desarrolladores se guiaron para priorizar la reparación de las clases smells. Este conjunto de 13 factores es el mismo con el que se ha trabajado en esta réplica, con el fin de estudiar si la ordenación de los 13 factores es similar a la obtenida en el estudio original. En esta réplica se incluyen sujetos (35) que sí están familiarizados con los proyectos que examinarán (15) para priorizar las clases con smells. En este caso se considerará solamente el smell God Class. Los resultados de la réplica, cuando se compararon las dos ordenaciones de factores, no son concluyentes, pero sí se ha observado que los dos primeros factores coinciden: "Importancia del Módulo" y "Relevancia de la tarea", y también coinciden los últimos. De esto se puede concluir que toda técnica de priorización de clases detectadas con smell debe tener en cuenta esos dos factores considerados los mas importantes por ambos grupos. Por tanto, las herramientas de soporte a la priorización deben ser capaces de capturar esta información. Otra conclusión obtenida es que el grado de familiaridad de los desarrolladores con los proyectos puede influir en la priorización, y que ésta puede depender del tipo de smell.
  • Artículo
    Comparación de herramientas de Detección de Design Smells
    Alkharabsheh, Khalid; Crespo, Yania; Manso, M. Esperanza; Taboada, José Ángel. Actas de las XXI Jornadas de Ingeniería del Software y Bases de Datos (JISBD 2016), 2016-09-13.
    La detección de Design Smells ha experimentado un auge en actividad entre los años 2010 y 2014. Proliferan las herramientas de detección automática pero se percibe un problema de falta de acuerdo en la identificación de Design Smells. En este trabajo se presentan dos experimentos. El primero es un experimento diseñado como estudio preliminar en el que se comparan una selección de 6 herramientas (inCode, inFusion, iPlasma, Together, JDeodorant y JSmellSensor) usándolas para detectar Design Smells en un proyecto software de código abierto. Del proyecto seleccionado se eligieron 100 clases aleatoriamente para este primer estudio exploratorio. El análisis consistió en valorar el grado de acuerdo en la identificación de Design Smells en el grupo de herramientas. En este primer experimento el estudio se realizó centrándose en la detección de dos tipos de Design Smells: God Class y Feature Envy. De este primer estudio se detectó un grupo de tres herramientas (inCode, inFusion, iPlasma) con un grado de acuerdo muy bueno. Se analizó que esto es así debido a que las tres fueron desarrolladas en el mismo grupo de investigación. Entre el resto de herramientas el acuerdo es inexistente (peor que al azar) o débil. El acuerdo débil se detectó entre el grupo de tres herramientas antes mencionadas y la herramienta JSmellSensor. JSmellSensor es una herramienta experimental desarrollada en nuestro grupo de investigación que parte de conocimiento aportado por iPlasma. Debido a estas circunstancias y para profundizar en el problema se diseñó una réplica. En esta réplica se comparan 5 herramientas (iPlasma, PMD, JDeodorant, DECOR, Together). Del grupo de tres herramientas identificado en el primer experimento se eligió como representante iPlasma. Se decidió que JSmellSensor no participase en esta réplica. En este segundo experimento se analizaron 12588 clases fruto de la preparación de un dataset con todas las clases de 24 proyectos de código abierto obtenidos de SourceForge. Este segundo experimento se centró únicamente en el estudio del acuerdo en la identificación de God Clss. Los resultados obtenidos en este segundo experimento muestran que tanto el acuerdo entre las herramientas tomadas conjuntamente como analizadas dos a dos es muy pobre.
  • Artículo
    Sobre el grado de acuerdo entre evaluadores en la detección de Design Smells
    Alkharabsheh, Khalid; Crespo, Yania; Manso, M. Esperanza; Taboada, José Ángel. Actas de las XXI Jornadas de Ingeniería del Software y Bases de Datos (JISBD 2016), 2016-09-13.
    La detección de Design Smells ha ido experimentado un auge en resultados de investigación publicados. La primera definición de Design Smells data del año 2000. La primera herramienta se reporta en 2002. A partir de 2004 comienza un crecimiento continuado, proliferando la aparición de nuevas herramientas para la detección automática de Design Smells. Particularmente a partir de 2009-2010 se produce un incremento notable en la actividad en este ámbito. La detección automática de Design Smells ha evolucionado a la par que las herramientas automáticas de refactoring. Sin embargo se constata que no ha sido comparable su adopción por parte de los desarrolladores en la producción y mantenimiento del software, con la forma en la que se han adoptado las herramientas de refactoring. En este trabajo partimos de la suposición de que la diferencia reside en la objetividad y pragmatismo de una operación de refactoring comparada con el grado de subjetividad que suponemos en la definición e identificación de Design Smells. Para estudiar este problema se diseñó una encuesta difundida vía correo electrónico en la que se obtuvieron 92 respuestas de personas tanto de la academia como de la industria acerca de la presencia de Design Smells en 5 clases de un proyecto de código abierto. El estudio se ha realizado centrándose en la detección de dos tipos de Design Smells: God Class y Feature Envy. La selección se basa en que son dos de los Design Smells más populares en la literatura y en que además se trata de Design Smells de diferente naturaleza en cuanto al ámbito y al efecto en el software. Se ha realizado un estudio en el que se valora el grado de acuerdo en la identificación de Design Smells entre los encuestados. En el trabajo se analizan la interrelación entre diferentes factores como la experiencia del evaluador, su contexto de trabajo, etc. Los resultados obtenidos muestran que no existe acuerdo en general y que es muy pobre en los casos en los que sí existe algún acuerdo. A partir de los resultados obtenidos se concluye con recomendaciones a tener en cuenta en las nuevas tendencias para la detección automática de Design Smells que pueden influir positivamente en la adopción por la industria de técnicas y herramientas para la detección de Design Smells.