REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE

REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE JUNIO 2015 VOLUMEN 3 NUMERO 3 ISSN 2314-2642

PUBLICADO POR EL GISI-UNLa

EN COOPERACIÓN POR LOS MIEMBROS DE LA RED DE INGENIERÍA DE SOFTWARE DE LATINOAMÉRICA

ARTÍCULOS TÉCNICOS

Numero especial dedicado a las XI Jornadas Iberoamericanas de Ingeniería de Software e Ingeniería del Conocimiento y Congreso Ecuatoriano en Ingeniería de Software (JIISIC-CEIS'2015)

Ingeniería de Software e Ingeniería del Conocimiento: Reporte de las JIISIC-CEIS’2015 Omar S. Gómez, Raúl A. Aguilar-Vera y José Antonio Pow-Sang

111-116

Sugerencias para la Inclusión de Temas de Medición de Software en un Currículo de Ingeniería de Software para Estudiantes de Pregrado Mónica Villavicencio, Alain Abran

117-126

Certificación de la Mantenibilidad del Producto Software: Un Caso Práctico Moisés Rodríguez, Óscar Pedreira, Carlos M. Fernández

127-134

Predictor Basado en Prototipos Difusos y Clasificación No-supervisada Anibal Vásquez, Enrique Peláez, Xavier Ochoa

135-140

Efectividad del Test-Driven Development: Un Experimento Replicado Oscar Dieste, Efraín R. Fonseca C., Geovanny Raura, Priscila Rodríguez

141-147

Modelo Neuronal de Estimación para el Esfuerzo de Desarrollo en Proyectos de Software (MONEPS) Mario G. Almache C, Geovanny Raura, Jenny A. Ruiz R., Efraín R. Fonseca C

148-154

REVISTA LATINAMERICANA

DE INGENIERIA DE SOFTWARE

La Revista Latinoamericana de Ingenieria del Software es una publicación tecnica auspiciada por la Red de Ingeniería de Software de Latinoamérica (RedISLA). Busca: [a] difundir artículos técnicos, empíricos y teóricos, que resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana como disciplina y profesión; [b] dar a conocer de manera amplia y rápida los desarrollos científico-tecnológicos en la disciplina de la región latinoamericana; y [c] contribuir a la promoción de la cooperación institucional entre universidades y empresas de la Industria del Software. La línea editorial, sin ser excluyente, pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas móviles, sistemas, plataformas virtuales de trabajo colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en conocimiento, entre otros; a través del intercambio de información científico y tecnológica, conocimientos, experiencias y soluciones que contribuyan a mejorar la cadena de valor del desarrollo en la industria del software.

Comité Editorial

RAUL AGUILAR VERA (México) Cuerpo Academico de Ingenieria de Software

Facultad de Matemáticas Universidad Autonoma de Yucatán

PAOLA BRITOS (Argentina)

Grupo de Ingeniería de Explotación de Información Laboratorio de Informática Aplicada Universidad Nacional de Río Negro

RAMON GARCÍA-MARTINEZ (Argentina)

Grupo de Investigación en Sistemas de Información Licenciatura en Sistemas

Departamento de Desarrollo Productivo y Tecnológico Universidad Nacional de Lanús

ALEJANDRO HOSSIAN (Argentina)

Grupo de Investigación de Sistemas Inteligentes en Ingeniería

Facultad Regional del Neuquén Universidad Tecnológica Nacional

BELL MANRIQUE LOSADA (Colombia) Programa de Ingeniería de Sistemas

Facultad de Ingeniería Universidad de Medellín

CLAUDIO MENESES VILLEGAS (Chile)

Departamento de Ingeniería de Sistemas y Computación Facultad de Ingeniería y Ciencias Geológicas

Universidad Católica del Norte

JONÁS MONTILVA C. (Venezuela) Facultad de Ingeniería

Escuela de Ingeniería de Sistemas Universidad de Los Andes

MARÍA FLORENCIA POLLO-CATTANEO (Argentina)

Grupo de Estudio en Metodologías de Ingeniería de Software

Facultad Regional Buenos Aires Universidad Tecnológica Nacional

JOSÉ ANTONIO POW-SANG (Perú) Maestría en Informática

Pontifica Universidad Católica del Perú

DIEGO VALLESPIR (Uruguay) Instituto de Computación

Universidad de la Republica

FABIO ALBERTO VARGAS AGUDELO (Colombia) Dirección de Investigación Tecnológico de Antioquia

CARLOS MARIO ZAPATA JARAMILLO (Colombia)

Departamento de Ciencias de la Computación y de la Decisión

Facultad de Minas Universidad Nacional de Colombia

Contacto

Dirigir correspondencia electrónica a:

Editor de la Revista Latinoamericana de Ïngenieria de Software RAMON GARCIA-MARTINEZ e-mail: [email protected]

e-mail alternativo: [email protected] Página Web de la Revista: http://www.unla.edu.ar/sistemas/redisla/ReLAIS/index.htm

Página Web Institucional: http://www.unla.edu.ar

Dirigir correspondencia postal a:

Editor de la Revista Latinoamericana de Ïngenieria de Software RAMON GARCIA-MARTINEZ Licenciatura en Sistemas. Departamento de Desarrollo Productivo y Tecnológico Universidad Nacional de Lanus Calle 29 de Septiembre No 3901. (1826) Remedios de Escalada, Lanús. Provincia de Buenos Aires. ARGENTINA.

Normas para Autores

Cesión de Derechos de Autor Los autores toman conocimiento y aceptan que al enviar una contribución a la Revista Latinoamericana de Ingenieria del Software, ceden los derechos de autor para su publicación electrónica y difusión via web por la Revista. Los demas derechos quedan en posesión de los Autores.

Políticas de revisión, evaluación y formato del envío de manuscritos La Revista Latinoamericana de Ingenieria del Software recibe artículos inéditos, producto del trabajo de investigación y reflexión de investigadores en Ingenieria de Software. Los artículos deben presentarse redactados en el castellano en el formato editorial de la Revista. El incumplimiento del formato editorial en la presentación de un artículo es motivo de retiro del mismo del proceso de evaluación. Dado que es una publicación electrónica no se imponen limites sobre la cantidad de paginas de las contribuciones enviadas. También se pueden enviar comunicaciones cortas que den cuenta de resultados parciales de investigaciones en progreso. Las contribuciones recibidas están sujetas a la evaluación de pares. Los pares que evaluaran cada contribución son seleccionados por el Comité Editorial. El autor que envíe la contribución al contacto de la Revista será considerado como el autor remitente y es con quien la revista manejará toda la correspondencia relativa al proceso de evaluación y posterior comunicación. Del proceso de evaluación, el articulo enviado puede resultar ser: [a] aceptado, en cuyo caso será publicado en el siguiente numero de la revista, [b] aceptado con recomendaciones, en cuyo caso se enviará al autor remitente la lista de recomendaciones a ser atendidas en la nueva versión del articulo y su plazo de envio; ó [c] rechazado, en cuyo caso será devuelto al autor remitente fundando el motivo del rechazo.

Temática de los artículos La Revista Latinoamericana de Ingeniería del Software busca artículos empíricos y teóricos que resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana como disciplina y profesión. La línea editorial pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas móviles, sistemas multimediales vinculados a la televisión digital, plataformas virtuales de trabajo colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en conocimiento, entre otros. Se privilegiarán artículos que contribuyan a mejorar la cadena de valor del desarrollo en la industria del software.

Política de Acceso Abierto La Revista Latinoamericana de Ingeniería de Software: Sostiene su compromiso con las políticas de Acceso Abierto a la información científica, al

considerar que tanto las publicaciones científicas como las investigaciones financiadas con fondos públicos deben circular en Internet en forma libre, gratuita y sin restricciones.

Ratifica el modelo de Acceso Abierto en el que los contenidos de las publicaciones científicas se encuentran disponibles a texto completo libre y gratuito en Internet, sin embargos temporales, y cuyos costos de producción editorial no son transferidos a los autores.

No retiene los derechos de reproducción o copia (copyright), por lo que los autores podrán disponer de las versiones finales de publicación, para difundirlas en repositorios institucionales, blogs personales o cualquier otro medio electrónico, con la sola condición de hacer mención a la fuente original de publicación, en este caso Revista Latinoamericana de Ingeniería de Software.

Lista de Comprobación de Preparación de Envíos Como parte del proceso de envío, se les requiere a los autores que indiquen que su envío cumpla con todos los siguientes elementos, y que acepten que envíos que no cumplan con estas indicaciones pueden ser devueltos al autor: 1. La contribución respeta el formato editorial de la Revista Latinoamericana de Ingenieria del

Software (ver plantilla). 2. Actualidad/Tipo de referencias: El 45% de las referencias debe hacerse a trabajos de publicados

en los últimos 5 años, así como a trabajos empíricos, para cualquier tipo de artículo (empírico o teórico).

3. Características artículos empíricos (análisis cuantitativo de datos): Se privilegian artículos empíricos con metodologías experimentales y cuasi experimentales, con pruebas estadísticas robustas y explicitación del cumplimiento de los supuestos de las pruebas estadísticas usadas.

4. Características artículos empíricos (análisis cualitativo de datos): Se privilegian artículos empíricos con estrategias de triangulación teórica-empírica, definición explícita de categorías orientadoras, modelo teórico de análisis, y análisis de datos asistido por computadora.

5. Características artículos de revisión: Para el caso de artículos de revisión, se evaluará que los mismos hayan sido desarrollados bajo el formato de meta análisis, la cantidad de referencias deben superar las 50, y deben explicitarse los criterios de búsqueda, bases consultadas y pertinencia disciplinar del artículo.

6. El artículo (en formato word y pdf) se enviará adjunto a un correo electrónico dirigido al contacto de la Revista en el que deberá constar la siguiente información: dirección postal del autor, dirección de correo electrónico para contacto editorial, número de teléfono y fax, declaración de que el artículo es original, no ha sido previamente publicado ni está siendo evaluado por otra revista o publicación. También se debe informar de la existencia de otras publicaciones similares escritas por el autor y mencionar la versión de la aplicación de los archivos remitidos (versión del editor de texto y del conversor a archivo pdf) para la publicación digital del artículo.

7. Loa Autores aceptan que el no cumplimiento de los puntos anteriores es causal de No Evaluación del articulo enviado.

Compromiso de los Autores de Artículos Aceptados La Revista Latinoamericana de Ingeniería del Software busca ser una revista técnica de calidad, en cuyo desarrollo estén involucrados los investigadores y profesionales latinoamericanos de la disciplina. En este contexto, los Autores de artículos aceptados asumen ante la Revista y la Comunidad Latinoamericana de Ingeniería del Software el compromiso de desempeñarse como pares evaluadores de nuevas contribuciones.

Omar S. Gómez, Raúl A. Aguilar-Vera y José Antonio Pow-Sang. 2015. Ingeniería de Software e Ingeniería del Conocimiento: Reporte de las JIISIC-CEIS’2015. Revista Latinoamericana de Ingeniería de Software, 3(3): 111-116, ISSN 2314-2642

111

Ingeniería de Software e Ingeniería del Conocimiento: Reporte de las JIISIC-CEIS’2015

Omar S. Gómez Prometeo-Senescyt

Escuela Superior Politécnica de Chimborazo Riobamba 060106, Ecuador

[email protected]

Raúl A. Aguilar-Vera Facultad de Matemáticas

Universidad Autónoma de Yucatán Mérida 97000, México

[email protected]

José Antonio Pow-Sang Pontificia Universidad Católica del Perú

San Miguel, Lima 32, Perú [email protected]

Resumen—En el presente documento se presenta el reporte de

las XI Jornadas Iberoamericanas de Ingeniería de Software e Ingeniería del Conocimiento así como del Congreso Ecuatoriano en Ingeniería de Software, celebrados en la Escuela Superior Politécnica de Chimborazo (ESPOCH) los días 4 y 5 de junio de 2015. De un total de 28 trabajos enviados, en esta edición se han aceptado 16. En este documento se presentan los títulos y resúmenes de los trabajos aceptados.

Palabras clave—JIISIC’2015, CEIS’2015, ingeniería de soft-ware, ingeniería del conocimiento, ecuador.

I. INTRODUCCIÓN La Ingeniería de Software y la Ingeniería del Conocimiento

son dos disciplinas relacionadas entre sí. Por ejemplo, enfoques basados en modelos comúnmente usados en la ingeniería del conocimiento pueden trasladarse al desarrollo de productos software como un modelo de proceso de construcción [1], puede decirse que ambas disciplinas convergen en un único ciclo de vida [2]. Con el fin de ofrecer un espacio Iberoamericano para la divulgación de investigaciones entre estas dos disciplinas surgen las JIISIC.

JIISIC o Jornadas Iberoamericanas de Ingeniería de Software e Ingeniería del Conocimiento han representado un foro de encuentro internacional de científicos y profesionales dedicados al estudio e investigación de la Ingeniería de Software y de la Ingeniería del Conocimiento. Su propósito fundamental es fomentar el contacto, la cooperación científica y profesional, así como la transferencia de tecnología en el ámbito Iberoamericano.

Desde su primera edición (2001), celebrada en Buenos Aires (Argentina), las JIISIC han convocado a un número cada vez más nutrido de asistentes, en Salvador de Bahía (Brasil), Valdivia (Chile), Madrid (España), Puebla (México), Lima (Perú), Guayaquil (Ecuador), Mérida (México), Lima (Perú), Medellín (Colombia). En esta edición 2015, regresan a Ecuador a la ciudad de Riobamba, la sultana de los Andes.

Por otra parte CEIS o Congreso Ecuatoriano en Ingeniería de Software surge de la necesidad de mantener un foro de discusión entre científicos, académicos y profesionales interesados en el estudio e investigación de la Ingeniería de Software en el Ecuador y la región.

El objetivo del CEIS es proporcionar un punto de encuentro para presentar y discutir resultados de investigaciones

realizadas en el Ecuador y en la región dentro del ámbito de la Ingeniería de Software. Como objetivo implícito, se pretende fomentar la colaboración entre las distintas partes interesadas en esta temática.

En esta edición JIISIC-CEIS’2015 se han recibido 28 trabajos de los cuales en base a las revisiones hechas por los miembros del comité de programa se han seleccionado 16 [3]; la tasa de aceptación ha sido del 57%. En esta edición se ha tenido la participación de colegas de diferentes países como Cuba, Ecuador, México, Perú, España y Canadá. El comité de programa agradece la participación de quienes eligieron JIISIC-CEIS'2015 para la difusión de sus trabajos de investigación; también agradecemos a los revisores miembros del comité científico su valiosa colaboración en el proceso de revisión. Estamos seguros que sus recomendaciones fueron valoradas positivamente por los autores de los trabajos aceptados, así como serán valoradas de forma positiva por aquellos autores cuyos trabajos no han sido seleccionados en esta edición.

Los trabajos presentados en este número especial de la Revista Latinoamericana de Ingeniería de Software (RELAIS) corresponden a versiones extendidas de los cinco trabajos que recibieron la mejor puntuación por parte del comité científico de las JIISIC-CEIS’2015. En el resto de secciones de este documento se presentan los títulos y resúmenes de los 16 trabajos aceptados en la edición 2015 de este evento.

II. ESTUDIO DEL TAMAÑO DE LOS DOCUMENTOS DE REQUERIMIENTOS DE SOFTWARE COMO FACTOR PARA LA

ESTIMACIÓN DEL ESFUERZO DE INSPECCIÓN DE REQUERIMIENTOS DE SOFTWARE

Autores: Carlos Monsalve, Rubén Ullón, Ricardo Maya y José Romero. Resumen: La inspección de documentos de requerimientos de software es una técnica que asegura calidad y reducción de costos en el ciclo de vida del desarrollo de software. Por otro lado, es crucial en la planificación de proyectos de software contar con métodos que permitan estimar esfuerzo basados en métricas y no únicamente en el juicio de expertos. Pese a esto, existe muy poco trabajo reportado orientado a la estimación de esfuerzo en tareas de inspección de documentos de requerimientos de software. En este artículo estudiamos la relación existente entre el tamaño de los documentos de requerimientos y el esfuerzo necesario para

Omar S. Gómez, Raúl A. Aguilar-Vera y José Antonio Pow-Sang. 2015. Ingeniería de Software e Ingeniería del Conocimiento: Reporte de las JIISIC-CEIS’2015.

Revista Latinoamericana de Ingeniería de Software, 3(3): 111-116, ISSN 2314-2642

112

su inspección. Para ello se realizó una experiencia en laboratorio con estudiantes de los últimos niveles de una carrera de grado de computación, quienes fueron entrenados en tareas de inspección. Los resultados permitieron establecer un modelo estadísticamente significativo para estimar esfuerzo en función del tamaño de los documentos inspeccionados [4].

III. EVALUACIÓN DE LA ACCESIBILIDAD EN SITIOS WEB CUBANOS

Autores: Yenier F. Moreno y Lisandra Armas. Resumen: En los últimos años, las nuevas Tecnologías de la Información y las Comunicaciones han generado un notable impacto en nuestra vida cotidiana. El usuario puede hacer uso intensivo de estas nuevas tecnologías iniciando trámites, gestionando transacciones, consultando información o hasta participando en espacios virtuales de comunicación. El propósito de la investigación ha sido evaluar el nivel de accesibilidad de sitios web cubanos, para lo cual se utilizó la herramienta TAW, que permite analizar, de acuerdo con la norma WCAG 2.0 la existencia de barreras en ellos, luego de un análisis exhaustivo se comprobó que ninguno de los sitios evaluados la supera. Se concluye recomendando realizar re-visiones y ajustes para resolver estos problemas y facilitar la accesibilidad web [5].

IV. EVALUACIÓN DE USABILIDAD EN HERRAMIENTAS EDUCATIVAS: UNA REVISIÓN SISTEMÁTICA

Autores: Freddy Paz, Claudia Zapata, César Olivares, Santiago Apaza y José A. Pow-Sang. Resumen: La usabilidad es un factor fundamental en la calidad de todo producto software. El sector educativo y enseñanza/aprendizaje no es la excepción. Por este motivo, varios métodos han sido propuestos con el objetivo de evaluar el nivel de usabilidad de los productos software. Sin embargo, esta gran cantidad de técnicas existentes torna compleja la elección del método más adecuado, lo cual justifica un estudio sobre las actuales tendencias, en miras de identificar los criterios más apropiados para realizar la elección correcta, en cada instancia de pruebas. El presente trabajo es una revisión sistemática de los estudios publicados entre el 2012 y el 2014, en los cuales se hayan realizado evaluaciones de usabilidad a plataformas informáticas orientadas al sector educativo y enseñanza-aprendizaje, con el propósito de identificar las actuales tendencias en el área. Se muestra un resumen de los métodos usados, y se reporta asimismo el número de usuarios o evaluadores participantes, el número de veces que se aplica el mismo método en un mismo estudio, la realización o no de una capacitación previa a la evaluación y la vinculación entre los desarrolladores de la aplicación y el equipo de evaluación [6].

V. APLICACIÓN DEL PARADIGMA DE LÍNEA DE PRODUCTO SOFTWARE PARA MODELAR UN SISTEMA FINANCIERO

Autores: Edison Espinosa, Gabriela Salguero y Paola Salguero. Resumen: El crecimiento exponencial del software y la necesidad de reducir tiempos y costos en la construcción de productos software, han hecho de la reutilización de componentes una práctica común hoy en día. El paradigma de línea de producto software se enfoca en la reutilización de componentes de forma planificada, que permite la reducción de costos tiempos y recursos en el desarrollo de software. En el proceso de línea de producto software se identifican y modelan las características comunes y variables de los productos de la línea, que permite crear un núcleo de componentes llamados core assets y establecer las características específicas que identifican a cada producto dentro de la línea. Para desarrollar

cada uno de los productos de la línea se usan los core assets y se desarrollan las características específicas que identifican a cada producto dentro de la línea. En este artículo se presenta el proceso que se llevó a cabo para identificar, modelar e implementar en una herramienta informática las características de un sistema financiero aplicando el paradigma de línea de producto software. Los resultados obtenidos hasta el momento son una matriz y algunos modelos donde se evidencian las características identificadas y el modelo de la línea del producto del sistema financiero [7].

VI. EFECTIVIDAD DEL TEST-DRIVEN DEVELOPMENT: UN EXPERIMENTO REPLICADO

Autores: Oscar Dieste, Efraín R. Fonseca, Geovanny Raura y Priscila Rodríguez. Resumen: Los métodos ágiles y sus prácticas asociadas, e.g.: Test-Driven Developement (TDD), son ampliamente utilizadas en la industria y han sido repetidamente sometidas a estudios empíricos. Antecedentes: N. Juristo y su equipo han realizado diversos experimentos en empresas y academia acerca de TDD. En general, los experimentos no muestran un efecto positivo de TDD en la calidad del código o la productividad de los programadores. Objetivo: Replicar el experimento UPM 2014 para reproducir sus resultados y secundariamente, estudiar el efecto de la experiencia del desarrollador en la efectividad de TDD. Método: Replicación experimental manteniendo similares el training y los materiales del experimento original. La replicación fue llevada a cabo en la Universidad de las Fuerzas Armadas ESPE sede Latacunga (ESPEL). Los sujetos experimentales fueron 17 estudiantes del Master en Ingeniería de Software. Resultados: Los resultados de la replicación confirman los efectos observados en UPM 2014. La efectividad de TDD ha resultado menor que ITL, aunque las diferencias no son significativas. La productividad y calidad del código producido por los estudiantes ESPEL cuando utilizan ITL y TDD es comparable a la de los estudiantes UPM, aunque menor en valores absolutos. Conclusiones: TDD no produce beneficios en calidad o poductividad, o al menos no de forma inmediata. Parece necesario que los sujetos experimentales reciban training intensivo para que los efectos de TDD sean evidentes [8].

VII. DETECCIÓN DE DEFECTOS CON Y SIN APOYO DE UN ENTORNO VIRTUAL COLABORATIVO INTELIGENTE EN CURSOS

INTRODUCTORIOS DE PROGRAMACIÓN Autores: Juan P. Ucán, Omar S. Gómez, Alejandro A.

Castillo y Raúl A. Aguilar. Resumen: El uso de entornos virtuales colaborativos facilita la comunicación, coordinación y cooperación en un grupo de personas. En el ámbito de las Tecnologías de la Información y la Comunicación (TIC) se han desarrollado entornos virtuales colaborativos para apoyar el aprendizaje de la programación. En ese trabajo se examina la efectividad en la detección de defectos en programas instrumentados con y sin apoyo de un entorno virtual colaborativo inteligente (EVCI) propio. Empleando un diseño experimental cruzado se conformaron 18 equipos de 2 y 3 estudiantes (en total 46) donde en dos sesiones los estudiantes trabajaron con y sin un EVCI en la detección de defectos en dos programas instrumentados. Los resultados sugieren una efectividad equivalente en la detección de defectos para quienes emplearon el ECVI (43.45%) como para quienes trabajaron de manera tradicional (45.33%). Se observa que es igualmente efectivo para este tipo de tarea (detección de defectos) trabajar de forma virtual a través de un ECVI que


113

hacerlo de manera tradicional (al mismo tiempo y en el mismo sitio) [9].

VIII. SOFTWARE MEASUREMENT FOR UNDERGRADUATES: SUGGESTIONS FOR A SOFTWARE ENGINEERING CURRICULUM

Autores: Mónica Villavicencio y Alain Abran. Resumen: Over the past decade, efforts have been made to develop an updated version of the Software Engineering Body of Knowledge (SWEBOK). Although this is a great contribution to the field, there is still a need for updating the software engineering curriculum guidelines. Building upon previous research, the present study addresses this need by providing a set of suggestions regarding the topics of software measurement to be emphasized in undergraduate programs. A revision of the bodies of knowledge and curriculum guidelines together with an examination of opinions from practitioners and teachers were performed. Results indicate that five software measurement topics are essential in a software engineering curriculum [10].

IX. CERTIFICACIÓN DE LA MANTENIBILIDAD DEL PRODUCTO SOFTWARE. UN CASO PRÁCTICO

Autores: Moisés Rodríguez, Óscar Pedreira y Carlos M. Fernández. Resumen: La calidad del software está adquiriendo durante los últimos años una gran importancia, principalmente debido a que el software está presente en prácticamente todo lo que nos rodea y se hace necesario asegurar su correcto funcionamiento. Sin embargo, hasta ahora la mayor parte de los estudios se han centrado en evaluar la calidad de los procesos de desarrollo, y aunque existen trabajos centrados en la calidad del producto software, no existe todavía una propuesta completa para la evaluación y certificación de la calidad del producto software, basada en la nueva familia de normas ISO/IEC 25000. El presente artículo expone un caso de estudio de evaluación, mejora y certificación de la mantenibilidad de un producto software, en el que han participado una empresa desarrolladora de software, un laboratorio de evaluación acreditado y una entidad de certificación. Para ello, se presentarán las características de este tipo de evaluaciones, el rol que cumple cada una de las entidades participantes y el proceso seguido desde la evaluación inicial hasta la certificación definitiva [11].

X. EVALUACIÓN DE LA CALIDAD EN PRODUCTOS SOFTWARE. EXPERIENCIA CUBANA HACIA LA ACREDITACIÓN

Autores: Yanet Brito y Tayché Capote. Resumen: Actualmente existe una tendencia generalizada a la evaluación de productos software a través del esquema de tercerización del servicio u outsourcing de pruebas, tanto para desarrolladores como para clientes, que exigen en sus productos un elemento diferenciador de la competencia. Para proveer servicios especializados de testing, el laboratorio debe emplear normas y modelos que le permitan certificar en dichos productos las características de calidad establecidas a escala internacional. Un requisito indispensable para ello es que el laboratorio esté acreditado según la ISO/IEC 17025:2006 “Requisitos generales para la competencia de los laboratorios de ensayo y de calibración”. El siguiente trabajo esboza el proceso de evaluación de software que se realiza en un laboratorio de pruebas al software que brinda servicios outsourcing y la implementación de normas internacionales establecidas para la acreditación de ensayos. La propuesta considera las normas, NC-ISO/IEC 9126-1:2005, ISO/IEC 14598 y NC-ISO/IEC 17025:2006 y la adecuación de esta última de manera novedosa

en el área del software, presente en el documento: Guía de requisitos complementarios. Como resultados la aplicación de la propuesta en un entorno real, evidenciándose excelentes resultados para su validación [12].

XI. USO DE HERRAMIENTAS DE COMPUTACIÓN EN LA NUBE PARA DEFINIR, PLANIFICAR, CONTROLAR PROYECTOS DE

INNOVACIÓN Y GENERACIÓN DE CONOCIMIENTO Autores: Pablo Quezada, Liliana Enciso y Juan Garbajosa.

Resumen: La Computación en la Nube se está convirtiendo en la mejor manera de entregar soluciones que satisfagan la necesidad actual de una mayor colaboración entre empresas, educación y sociedad. En este contexto el aprendizaje de la Innovación como instrumento de desarrollo de productos software es importante durante la vida profesional de un Ingeniero en Sistemas Informáticos y Computación ya que conlleva a transformar tareas rutinarias en tareas automatizadas, de igual forma le permitirá gestionar procesos, enfocados en alinear los servicios de Tecnologías de la Información (TI) a las necesidades de las empresas con énfasis en los beneficios que puede percibir el cliente final adicionado el factor de I+D+I para crear un producto innovador. El presente trabajo se enfoca en el uso de herramientas de Computación en la Nube (CN) en sus fases: definición, planificación y control de proyecto de software con base en la innovación como herramienta de desarrollo y generación de conocimiento. Las herramientas de Computación en la Nube analizadas fueron: Alfresco, Redbooth, DotProject, Dealines, Redmine. El uso de estas herramientas permitió obtener información para formular un cuerpo de conocimiento en el contexto de proyectos [13].

XII. MODELO NEURONAL DE ESTIMACIÓN PARA EL ESFUERZO DE DESARROLLO EN PROYECTOS DE SOFTWARE (MONEPS)

Autores: Mario G. Almache, Jenny A. Ruiz, Geovanny Raura y Efraín R. Fonseca. Resumen: La estimación temprana del esfuerzo para la construcción de un producto software, es crucial en la previsión del costo y tiempo necesarios para el desarrollo de software. Los modelos y técnicas para la estimación del esfuerzo presentan, como principal inconveniente, la poca precisión en las predicciones realizadas, y generalmente se hace una mínima consideración de los aspectos no funcionales del software. Se propone la construcción de un modelo de estimación para el esfuerzo en el desarrollo de software, denominado MONEPS, que pretende mejorar la precisión en la estimación del esfuerzo, utilizando una Red Neuronal Artificial (RNA) en Backpropagation, cuya capa de entrada se estructura sobre la base de un conjunto de características y atributos tomados de la norma ISO 25000 de la calidad del software. La RNA fue entrenada con datos recopilados de aplicaciones desarrolladas en el ámbito académico, de las cuales se conocían sus tiempos de desarrollo y costos asociados. Las estimaciones de tiempo y costo, para dos casos de prueba, muestran más precisión en el modelo neuronal, en comparación con los modelos Cocomo-81 y COCOMO-II. MONEPS ha logrado la convergencia de aspectos funcionales y no funcionales para mejorar la precisión en la estimación de dicho esfuerzo [14].

XIII. INTEGRACIÓN DE METODOLOGÍAS ÁGILES EN EL DESARROLLO DE UN SISTEMA DE MONITOREO INALÁMBRICO PARA MEDIR LA CONTAMINACIÓN DEL AIRE EN TIEMPO REAL

Autores: Walter Fuertes, Diego Carrera, César Villacís, Fernando Galárraga, Theofilos Toulkeridis y Hernán Aules.



114

Resumen: Este artículo presenta el proceso de desarrollo de un sistema de monitoreo inalámbrico de bajo costo, basado en un modelo distribuido multicapa, que en combinación con la plataforma Arduino, permite medir parámetros referenciales de calidad de aire. Para llevarlo a cabo, se combinaron metodologías ágiles como Scrum y Extreme Programming con el propósito de garantizar la calidad del software. El dispositivo electrónico está equipado con tres sensores que miden la concentración de monóxido de carbono, dióxido de carbono y densidad del polvo, con la capacidad de conectarse al Internet para la transmisión, en tiempo real, de la información recolectada utilizando una API desarrollada en C/C++. La prueba de concepto se la aplicó en las ciudades de Quito, Amaguaña y el Tena de Ecuador, con resultados positivos, tanto en el funcionamiento del software y hardware que componen el prototipo, como en la medición referencial de la concentración de los contaminantes del aire [15].

XIV. PROPUESTA DE DIRECTRICES PARA EL ÁREA DEL CONOCIMIENTO “GESTIÓN DE PROCESOS ORGANIZACIONALES”

DEL MCDAI Autores: Danay Ramírez y Olga L. Rodríguez. Resumen:

En la actualidad, la Industria Cubana del Software (ICSW) está compuesta mayormente por micro, pequeñas y medianas empresas (PYMES), las cuales no implementan los modelos y estándares existentes a nivel mundial. La aplicación de estos modelos y estándares existentes en las PYMES es difícil, ya que están enfocados generalmente a las grandes empresas de software, y no tienen la orientación o el nivel de detalle que les permita adoptarlos. Es por este motivo que surge la necesidad de crear el Modelo de Calidad para el Desarrollo de Aplicaciones Informáticas (MCDAI), tomando como referencia los existentes pero adaptándolos al contexto cubano. Su principal objetivo es guiar y estandarizar la producción de software en el país. El mismo cuenta con 12 procesos bases, los cuales actualmente se están definiendo en una 1ra versión. Uno de ellos es el proceso base Gestión de Procesos de la Organización (GPO), el cual consiste en garantizar un marco adecuado para la gestión de los procesos organizacionales, posibilitando definir sus objetivos, procesos, repositorios, estándares del entorno de trabajo y modelos de ciclo de vida, así como gestionar los recursos de la organización. En esta investigación se presenta una propuesta del proceso GPO, donde se proponen 11 directrices para alcanzar una correcta gestión de procesos, las cuales fueron validadas en Grupos Técnicos de Trabajo (TWG) conformados por especialistas en el tema pertenecientes a diferentes empresas de la ICSW [16].

XV. ADQUISICIÓN DEL CONOCIMIENTO EN EL PROCESO DE COMPOSICIÓN MUSICAL EN BASE A TÉCNICAS DE INTELIGENCIA

ARTIFICIAL Autores: Efraín Astudillo, Pedro Lucas y Enrique Peláez.

Resumen: Generalmente, la composición musical es ejecutada por un proceso creativo en base a un amplio conocimiento de la teoría musical. Sin embargo, es posible crear piezas musicales extendiendo ese conocimiento aprendido en la academia. El propósito de este artículo es analizar y proponer representaciones abstractas, basadas en técnicas de Inteligencia Artificial, para la extracción del conocimiento en este proceso de composición e ir más allá de los tradicionales conceptos musicales. Los resultados de esta investigación contribuirán a entender la interacción de los elementos involucrados en el proceso de composición permitiendo el desarrollo de sistemas inteligentes para esta tarea y brindando soporte a los

compositores en la realización de música experimental. Además, se presentan los resultados de las pruebas realizadas con una de las representaciones pertenecientes al modelo completo propuesto para el conocimiento musical, donde se generaron melodías que fueron evaluadas estéticamente y sometidas a una Prueba de Turing [17].

XVI. PATRONES DE USO DOCENTE DE EVAS EN LA ESCUELA DE INGENIERÍA EN SISTEMAS INFORMÁTICOS DE LA ESPOCH Autores: Gonzalo Samaniego y Luis Marqués. Resumen: El

presente trabajo encuentra y valora patrones de uso docente de los Entornos Virtuales de Aprendizaje (EVAs) de los profesores de la Escuela de Ingeniería en Sistemas (EIS) de la Facultad de Informática y Electrónica (FIE) de la Escuela Superior Politécnica de Chimborazo (ESPOCH). Se utiliza un procedimiento en base a los logs del apartado “Informes” de los EVAs, que permite determinar y analizar variables tales como el lugar, horario y fecha frecuente de trabajo, los diferentes niveles de interacción y los recursos y actividades generados a lo largo de nueve semestres académicos. Los resultados evidencian la transición del lugar habitual de trabajo de los docentes en los EVAs desde la ESPOCH hacia la CASA, el aumento progresivo del uso e interacción en los EVAs, el uso reiterativo de un grupo de recursos y actividades, entre otros [18].

XVII. PREDICTOR BASADO EN PROTOTIPOS DIFUSOS Y CLASIFICACIÓN NO SUPERVISADA

Autores: Aníbal Vásquez, Enrique Peláez y Xavier Ochoa. Resumen: La construcción de prototipos difusos es un método que permite describir a los elementos más representativos de un clúster, a través de su tipicidad. Los prototipos, como los datos más representativos de cada clúster, pueden ser usados en un proceso de clasificación como datos de entrenamiento. Estos prototipos y los clusters pueden ser construidos mediante algoritmos de clustering difuso; los clusters representados por los prototipos poseen variables descriptivas y atributos que pueden ser asociados a nuevos datos. El siguiente trabajo propone una arquitectura que utiliza herramientas de clustering y prototipado difuso, para clasificación no-supervisada y predicción a través de la extracción de variables descriptivas. El desarrollo de un caso de estudio permitió validar el modelo de clasificación para predecir el riesgo de falla en el rendimiento académico de estudiantes, basado en su carga académica y rendimiento, en la selección de cursos antes de registrarse, con un porcentaje de certeza significativo [19].

REFERENCIAS [1] R. Studer, V. R. Benjamins, and D. Fensel. Knowledge

engineering: Principles and methods. Data & Knowledge Engineering, Volume 25, Issues 1–2, March 1998, p. 161–197.

[2] F. Alonso, N. Juristo, J. L. Maté, and J. Pazos. Software engineering and knowledge engineering: Towards a common life cycle. Journal of Systems and Software, Volume 33, Issue 1, April 1996, p. 65–79.

[3] O. S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors. Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., May 2015. ISBN:978-1-5108-0208-7.

[4] C. Monsalve, R. Ullón, R. Maya, and J. Romero. Estudio del tamaño de los documentos de requerimientos de software como factor para la estimación del esfuerzo de inspección de requerimientos de software. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas


115

Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 1–12.

[5] Y. F. Moreno, and L. Armas. Evaluación de la accesibilidad en sitios web cubanos. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 13–26.

[6] F. Paz, C. Zapata, C. Olivares, S. Apaza, and J. A. Pow-Sang. Evaluación de usabilidad en herramientas educativas: una revisión sistemática. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 27–38.

[7] E. Espinosa, G. Salguero, and P. Salguero. Aplicación del paradigma de línea de producto software para modelar un sistema financiero. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 39–52.

[8] O. Dieste, E. R. Fonseca, G. Raura, and P. Rodríguez. Efectividad del test-driven development: un experimento replicado. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 53–64.

[9] J. P. Ucán, O. S. Gómez, A. A. Castillo, and R. A. Aguilar. Detección de defectos con y sin apoyo de un entorno virtual colaborativo inteligente en cursos introductorios de programación. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 65–78.

[10] M. Villavicencio, and A. Abran. Software measurement for undergraduates: Suggestions for a software engineering curriculum. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 79–92.

[11] M. Rodríguez, O. Pedreira, and C. M. Fernández. Certificación de la mantenibilidad del producto software. Un caso práctico. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 93–106.

[12] Y Brito, and T. Capote. Evaluación de la calidad en productos software. Experiencia cubana hacia la acreditación. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 107–120.

[13] P. Quezada, L. Enciso, and J. Garbajosa. Uso de herramientas de computación en la nube para definir, planificar, controlar proyectos de innovación y generación de conocimiento. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 121–132.

[14] M. G. Almache, J. A. Ruiz, G. Raura, and E. R. Fonseca. Modelo neuronal de estimación para el esfuerzo de desarrollo en proyectos de software (MONEPS). In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 133–146.

[15] W. Fuertes, D. Carrera, C. Villacís, F. Galárraga, T. Toulkeridis, and H. Aules. Integración de metodologías ágiles en el desarrollo de un sistema de monitoreo inalámbrico para medir la contaminación del aire en tiempo real. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 147–158.

[16] D. Ramírez, and O. L. Rodríguez. Propuesta de directrices para el área del conocimiento "Gestión de Procesos Organizacionales". In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 159–170.

[17] E. Astudillo, P. Lucas, and E. Peláez. Adquisición del conocimiento en el proceso de composición musical en base a técnicas de inteligencia artificial. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 171–184.

[18] G. Samaniego, and L. Marqués. Patrones de uso docente de EVAs en la escuela de ingeniería en sistemas informáticos de la ESPOCH. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 185–196.

[19] A. Vásquez, E. Peláez, and X. Ochoa. Predictor basado en prototipos difusos y clasificación no supervisada. In O.S. Gómez, G. Arcos, L. Aguirre, E. Villa, and R. H. Rosero, editors, Ingenieria de Software e Ingenieria del Conocimiento. Jornadas Iberoamericanas. 11th (JIISIC’2015). Curran Associates, Inc., Riobamba, 2015, p. 197–206.

Omar S. Gómez es Ingeniero en Computación por la Universidad de Guadalajara (México, 2001), Maestro en Ingeniería de Software por el Centro de Investigación en Matemáticas (México, 2005), Doctor en Software y Sistemas por la Universidad Politécnica de Madrid (España, 2012), Post-Doctorado en la Universidad de Oulu (Finlandia,

2014). Actualmente es investigador Prometeo-Senescyt adscrito a la Escuela Superior Politécnica de Chimborazo (Ecuador). Su trabajo de investigación se centra en experimentación en ingeniería de software así como en temas relacionados con la calidad y el diseño de software.

Raúl A. Aguilar-Vera es Licenciado en Ciencias de la Computación por la Universidad Autónoma de Yucatán, Doctor en Informática por la Universidad Politécnica de Madrid, España. Actualmente es profesor de tiempo completo en la Facultad de Matemáticas de la Universidad Autónoma de Yucatán. Su trabajo de investigación

incluye las siguientes áreas: Ingeniería de Software e Informática Educativa.

José Antonio Pow-Sang es Doctor en Ingeniería Informática y Máster en Ingeniería del Software por la Universidad Politécnica de Madrid, España, y es Ingeniero Informático por la Pontificia Universidad Católica del Perú (PUCP). Es profesor principal de la PUCP y actualmente se desempeña como Director Ejecutivo de la Escuela de Posgrado

y Director de la Maestría en Informática en la PUCP. Fue por cinco años coordinador de la especialidad de Ingeniería Informática, y durante ese periodo participó en la acreditación de este programa con ICACIT (Perú), ABET (EEUU) y CEAB (Canadá). Ha participado en un proceso de evaluación de ICACIT y actualmente está habilitado



116

por esta institución como evaluador. Representó al país en el área de Informática en el proyecto Alfa Tuning América Latina, proyecto en el que se definieron las competencias genéricas y específicas que deberían tener los profesionales en el área. Ha participado como conferencista, ponente, organizador, miembro del comité científico de conferencias internacionales en sus áreas de investigación. Es actualmente el segundo investigador en el país con más publicaciones en Ciencias de la Computación según Scopus®. Sus áreas de investigación son Experimentación en Ingeniería del Software, Métricas y Estimación en Proyectos de Software, Interacción Persona-Computador y Educación en Informática.

Mónica Villavicencio y Alain Abran N. 2015. Sugerencias para la Inclusión de Temas de Medición de Software en un Currículo de Ingeniería de Software para Estudiantes de Pregrado Revista Latinoamericana de Ingeniería de Software, 1(1): 117-126, ISSN 2314-2642

117

Sugerencias para la Inclusión de Temas de Medición de Software en un Currículo de Ingeniería de

Software para Estudiantes de Pregrado

Mónica Villavicencio Facultad de Ingeniería en Electricidad y Computación

Escuela Superior Politécnica del Litoral (ESPOL) Guayaquil, Ecuador

[email protected]

Alain Abran Deptartamento de Ingeniería de Software y TI

École de technologie supérieure Montreal, Canadá

[email protected]

Resumen—En la última década, se han realizado esfuerzos para desarrollar una versión actualizada del Cuerpo de Conocimiento de la Ingeniería de Software (SWEBOK por sus siglas en inglés). Aunque esta actualización representa una gran contribución para este campo, aún existe la necesidad de actualizar las guías curriculares de ingeniería de software. Tomando como base investigaciones previas, el presente estudio aborda la necesidad de proporcionar una serie de sugerencias respecto a temas de mediciones de software que deben enfatizarse en programas universitarios. Para ello, se efectuó una revisión de los cuerpos de conocimiento relacionados a mediciones de software, así como de las guías curriculares de ingeniería de software a nivel de pregrado. Todo esto acompañado de un análisis de opiniones de profesionales de ingeniería de software en ejercicio de sus funciones, así como de profesores universitarios que imparten dicha cátedra. Los resultados indican que cinco temas de medición de software son esenciales en un currículo de ingeniería de software.

Palabras claves— Guías curriculares; ingeniería de software; educación superior; mediciones de software.

I. INTRODUCCION El SWEBOK (Software Engineering Body of Knowledge)

es una guía que enmarca los contenidos de la disciplina de la Ingeniería de Software. Uno de los objetivos de SWEBOK es proporcionar las bases para el desarrollo de currículos de estudio [1]. La versión original de la guía SWEBOK (año 2004) fue la piedra angular para generar el Conocimiento Educativo de la Ingeniería de Software (Software Engineering Education Knowledge - SEEK), el mismo que fuera usado para desarrollar las guías curriculares para programas universitarios de ingeniería de software (SE2004) [2]. Estas guías proporcionan sugerencias a los educadores sobre el contenido de los programas, la forma de enseñar los contenidos en contextos diferentes, y las habilidades (técnicas y de gestión) que necesitan los estudiantes de pregrado para afrontar los procesos de desarrollo de software. De acuerdo a estos lineamientos curriculares, una de las siete características deseables en el trabajo de los ingenieros de software es: “Los ingenieros miden cosas, y cuando es apropiado, trabajan cuantitativamente; calibrando y validando sus mediciones; y usando aproximaciones basadas en la experiencia y datos empíricos” [2]. Esta característica conecta la definición de ingeniería de software al perfil esperado de un ingeniero en software. La ingeniería de software se define como “la aplicación de un enfoque sistemático, disciplinado, cuantificable al desarrollo, operación, y mantenimiento de

software; esto es, la aplicación de ingeniería al software” [1]. La característica antes mencionada es también evidente dentro de las directrices curriculares SE2004 (desarrollados en conjunto entre ACM & IEEE), en donde existe una presencia extensa de temas de medición de software. SE2004 permanece -hasta la presente fecha- como un referente para el desarrollo curricular.

En la última década, se han realizado esfuerzos para desarrollar una versión actualizada de la guía SWEBOK, publicada en el año 2014 como SWEBOK v3.0. Con respecto a la versión inicial SWEBOK 2004, la versión 2014 extiende de 10 a 15 las áreas de conocimiento (KA – Knowledge Areas); áreas que contienen temas relacionados a la medición del software. Es importante anotar que en el año 2010, un área de conocimiento completa de mediciones de software fue desarrollada por Abran et al [3], obteniendo como resultado un Cuerpo de Conocimiento de Mediciones de Software (Software Measurement Body of Knowledge). Este nuevo cuerpo de conocimiento – incluido en la enciclopedia de ingeniería de software – integra y expande el conocimiento relacionado a mediciones de software contenido a lo largo de SWEBOK 2004.

Se espera que la reciente versión del SWEBOK (v3.0) contribuya a la actualización de las directrices curriculares de ingeniería de software. Dentro de este contexto, este artículo presenta sugerencias para incluir temas esenciales de medición de software en programas universitarios a nivel de pregrado.

Este artículo está organizado de la siguiente manera: la sección II presenta un mapeo de temas relacionados a la medición de software entre las directrices curriculares (SE2004) y los Cuerpos de Conocimiento afines. La sección III resume las opiniones de profesores universitarios y profesionales de ingeniería de software en ejercicio acerca de los temas de mediciones de software que deben enseñarse en programas universitarios. La sección IV presenta sugerencias para actualizar las directrices curriculares de ingeniería de software respecto a los temas de medición de software. Finalmente, la sección V concluye el artículo.

II. MAPEO DE TEMAS DE MEDICIÓN DE SOFTWARE Para el mapeo de los temas de medición de software,

usamos tres documentos: 1. Las directrices curriculares para programas

universitarios en ingeniería de software SE2004 [2]; 2. SWEBOK versión 3.0 [1]; y

Mónica Villavicencio y Alain Abran N. 2015. Sugerencias para la Inclusión de Temas de Medición de Software en un Currículo de Ingeniería de Software para Estudiantes de Pregrado


118

3. El cuerpo de conocimiento de mediciones de software [3].

El capítulo 4 del SE2004 presenta el SEEK (Software Engineering Education Knolwedge), el mismo que propone el conocimiento de ingeniería de software que los estudiantes de pregrado deberían adquirir. El SEEK está organizado en tres niveles jerárquicos: áreas de conocimiento; unidades de conocimiento; y temas (ver un ejemplo en la Tabla I). SEEK considera diez áreas de conocimiento; 1) Fundamentos de computación; 2) Fundamentos de Matemáticas e Ingeniería; 3) Práctica Profesional; 4) Modelamiento y Análisis de Software; 5) Diseño de Software ; 6) Verificación y Validación de Software; 7) Evolución de Software; 8) Procesos de Software; 9) Calidad de Software; y 10) Gestión del Software.

Para cada tema, el SEEK sugiere:

Niveles de aprendizaje (N) de acuerdo a la versión original de la Taxonomía de Bloom [4], y

Relevancia (R) de los temas (esencial E, deseable D, y opcional O)

La versión original de la Taxonomía de Bloom tiene seis niveles de aprendizaje, denominados como: conocimiento, comprensión, aplicación, análisis, síntesis y evaluación. De éstos, los tres primeros niveles fueron usados en SEEK (conocimiento K, comprensión C, y aplicación A). Un ejemplo de la jerarquía de SEEK se muestra en la Tabla I donde los temas Mediciones y Métricas tienen el nivel de aprendizaje K (conocimiento) y relevancia E (esencial).

TABLA I. EJEMPLO DE JERARQUIA EN EL SEEK

Areas de conocimiento

SEEK

Unidades de conocimiento Tópicos N R

Mediciones y métricas K E Fundamentos de matemáticas e ingeniería

Fundamentos de Ingeniería para el Software Teoría de mediciones C E

Después de revisar las directrices curriculares, se identificó

que seis áreas de conocimiento del SEEK incluyen temas de mediciones de software (ver las dos primeras columnas de la Tabla II), todas estas áreas son consideradas esenciales (E) en el currículo 2004. Habiendo identificado estas seis áreas, buscamos información complementaria en otros Cuerpos de Conocimiento (SWEBOK y el cuerpo de conocimiento de mediciones de software). En el caso de SWEBOK 2004, éste incluye 10 áreas de conocimiento en las que se incluyen temas relacionados a medición de software presentados en forma dispersa a lo largo del contenido de ellas. Esta dispersión motivó la creación de un nuevo cuerpo de conocimiento de Mediciones de Software en el 2010, con el objetivo de agrupar todos los tópicos correspondientes [3]. El cuerpo de conocimiento de Mediciones de Software divide el conocimiento en seis grandes tópicos: 1) Conceptos Básicos; 2) Procesos de Medición; 3) Mediciones por fase del ciclo de vida del software (SLC); 4) Técnicas y herramientas; 5) Datos cuantitativos; y 6) Estándares de Mediciones. Cada tópico es dividido en sub-tópicos. Por ejemplo, el tópico Conceptos Básicos está dividido en tres sub-tópicos: fundamentos; conceptos y definiciones; y modelos de medición de software.

La versión actual de SWEBOK (v3.0) considera 15 áreas de conocimiento (KAs) divididas en tópicos y sub-tópicos: 11

de las 15 KAs contienen temas de medición de software. Por ejemplo, el área de conocimiento de Gestión de Ingeniería de Software tiene el tópico Mediciones en Ingeniería de Software.

La Tabla II muestran el mapeo entre SEEK (incluido en SE2004), el cuerpo de conocimiento de Mediciones de Software, y SWEBOK v3.0. El mapeo fue efectuado en base a las directrices curriculares para ver si estas están alineadas con dichos cuerpos de conocimiento. Por lo tanto, buscamos los temas de medición de software contenidos en SEEK dentro de los otros cuerpos de conocimiento. Al hacer esto, observamos que el tema Métricas de Diseño incluidos en el SEEK no está considerado ni en SWEBOK v3.0 ni en el cuerpo de conocimiento de Mediciones de Software; Además, observamos que el tema Procesos de Software en equipo está incluido marginalmente en SWEBOK v3.0 y no está incluido en el cuerpo de conocimiento de Mediciones de Software (Ver Tabla II- adaptadas de [5]).

El mapeo en la dirección opuesta, es decir, desde el SWEBOK v3.0 hacia las directrices curriculares, se muestra en la Sección IV donde se presentan sugerencias para un nuevo currículo- considerando sólo el análisis de los temas de medición de software (ver Tabla V).

III. PRIORIDADES: OPINIONES DE ACADÉMICOS Y PROFESIONALES EN EJERCICIO

Las opiniones de profesores y profesionales acerca de los temas de mediciones de software que deberían ser priorizados en las universidades se recopilaron en dos fases: 1) una encuesta vía web a los profesionales en ejercicio y 2) un estudio Delphi con dos paneles de expertos (profesionales en ejercicio y profesores universitarios).

A. Encuesta vía web La encuesta se realizó a profesionales en ejercicio –

específicamente profesionales de organizaciones privadas o públicas que trabajan en mejoramiento de procesos de software o como especialistas en mediciones de software. La encuesta buscaba identificar: 1) el nivel de importancia -percibido por los profesionales- respecto a las mediciones de software; 2) la apreciación de las organizaciones sobre el conocimiento de mediciones de software que poseen los estudiantes recién graduados cuando se convierten en sus empleados; y 3) los tópicos específicos de medición de software que deberían enfatizarse en los programas de ingeniería de software desde el punto de vista del profesional en ejercicio. Para este propósito, se diseñó un cuestionario con una lista de 12 tópicos de medición de software, los cuales fueron tomados del Cuerpo de Conocimiento de Mediciones de software [3] y la guía SWEBOK capítulo 12 (Borrador de Febrero 4 de 2008) [6]. En ese momento, el capítulo 12 era el Área de Conocimiento de Mediciones de Software en SWEBOK. Cincuenta y dos profesionales de 18 países contestaron el cuestionario durante la primavera de 2011. Detalles de la encuesta se encuentran disponibles en [7]. De esta encuesta, identificamos los tópicos que necesitaban ser enfatizados en los cursos universitarios. Para el análisis de resultados, clasificamos a los encuestados en profesionales en ejercicio de instituciones certificadas y no certificadas. La tabla III muestra 11 temas de medición de software de acuerdo al orden de preferencia seleccionado por los participantes.


119

TABLA II. MAPEO ENTRE CUERPOS DEL CONOCIMIENTO

Software Engineering Education Knowledge (SEEK) y SE2004

Cuerpo de Conocimiento de Mediciones de Software SWEBOK v3.0

Areas de Conocimiento Tópicos Tópicos Sub Tópicos Areas de

Conocimiento Tópicos

Métricas y mediciones Fundamentos Fundamentos de

Matemáticas e Ingeniería Teoría de mediciones

Conceptos Básicos Definiciones y

conceptos

Fundamentos de Ingeniería para

el Software Mediciones

Mediciones de atributos del diseño (ej. Acoplamiento,

cohesión,etc.)

Mediciones en el ciclo de vida (SLC)

Diseño de Software

Diseño de Software

Análisis y evaluación de la

calidad del diseño Diseño de

Software Métricas de diseño (ej. Factores

arquitectónicos, interpretación, etc.)

No encontrado No encontrado

Métricas y mediciones (ej. Confiabilidad,

usabilidad, etc.)

Análisis de reporte de fallas

Verificación y Validación del

Software

Análisis de defectos


Pruebas de Software

Pruebas de Software

Mediciones relacionadas a

las pruebas

Análisis y control de la calidad (ej. Prevención de

defectos, métricas de calidad, análisis de

causa raíz, etc.)

Técnicas de medición

Proceso de software individual (modelo,

definición, mediciones, análisis,

mejora)

Técnicas y herramientas

Técnicas de medición Procesos de

software

Procesos de software en equipo (modelo,

definición, organización,

mediciones, análisis, mejora)

No encontrado No encontrado

Proceso de ingeniería de

software

Mediciones de software

Modelos and métricas de calidad

del Software Calidad del Software Métricas y

mediciones de la calidad del producto


Calidad del Software


Consideraciones prácticas


Mediciones de software para constucción y

pruebas Estimación del esfuerzo

Técnicas y herramientas

Herramientas para

mediciones

Planificación de proyectos de

software Administración

del Software

Medición y análisis de resultados

El proceso de medición

Realizar y evaluar el proceso de medición

Gestión de la Ingeniería de

Software

Mediciones en ingeniería de

software

Uno de los tópicos, “Medidas de mantenimiento de software”, no aparece en la tabla III ya que no fue seleccionado por ninguno de los participantes.

Al observar las cinco primeras posiciones de la tabla, podemos notar similitudes y diferencias. Por ejemplo, los profesionales de ambos tipos de organizaciones concordaron en



120

seleccionar “Conceptos Básicos” como el tema más importante a cubrirse en los cursos universitarios. Adicionalmente, otros dos temas están listados dentro de los cinco primeros: “Técnicas y herramientas” y “El proceso de medición.” Respecto a las diferencias, puede observarse que los profesionales que trabajan en organizaciones no certificadas ubicaron el tema “Mediciones para la Gestión de Ingeniería de Software" en segundo lugar de importancia, mientras que los de organizaciones certificadas no lo consideraron dentro de los cinco primeros. Igualmente, los profesionales provenientes de organizaciones certificadas dieron una importancia considerable a los temas “Estándares de Medición” y “Mediciones para la fase de requerimientos” mientras que aquellos de organizaciones no certificadas no lo hicieron.

TABLA III. TEMAS QUE NECESITAN MAYOR ÉNFASIS DE ACUERDO A LA OPINIÓN DE PROFESIONALES

Temas seleccionados por profesionales en ejercicio

# Organizaciones No-Certificadas Organizaciones Certificadas

1 Conceptos Básicos Conceptos Básicos

2 Medición en la Gestión de Ingeniería de software El proceso de medición

3 Técnicas y herramientas Estándares de Medición

4 Mediciones relacionadas a la calidad

Mediciones para fase de requerimientos

5 El proceso de medición Técnicas y herramientas

6 Estándares de Medición Mediciones relacionadas a la calidad

7 Mediciones para fase de requerimientos Mediciones para pruebas

8 Repositorios para datos cuantitativos

Medición en la Gestión de Ingeniería de software

9 Mediciones para la fase de construcción

Mediciones para la fase de diseño

10 Mediciones para la fase de diseño

Repositorios para datos cuantitativos

11 Mediciones para pruebas Mediciones para la fase de construcción

B. Estudio Delphi Los estudios Delphi son comúnmente usados en

investigación educativa para diseño y perfeccionamiento curricular [8-12]. Estos estudios siguen un proceso de comunicación estructurado en varias iteraciones (rondas) para consolidar las opiniones de expertos acerca de un sujeto de estudio que está siendo investigado [8-17].

Nuestro Delphi fue diseñado para llegar a un consenso entre profesores universitarios y profesionales en ejercicio – con probada experiencia en el área de ingeniería de software - respecto a temas de mediciones de software que deben enseñarse a estudiantes de grado. En el estudio también se preguntó a los expertos acerca de los niveles de aprendizaje que los estudiantes deberían alcanzar de acuerdo a la taxonomía de Bloom.

El estudio Delphi tuvo dos paneles de expertos en mediciones de software: profesores universitarios y profesionales. Los criterios usados para invitar a los participantes de los paneles fue el siguiente:

Profesionales

Demostrar cinco o más años de experiencia profesional en mediciones de software, trabajando en programas de mejora de procesos de software y/o en programas de mediciones de software como un miembro del equipo o especialista.

Participar como miembro de un comité o asociación de mediciones de software en su país de origen o fuera de él (no obligatorio, pero preferible).

Haber publicado artículos sobre mediciones de software relacionados con su experiencia profesional.

Demostrar educación post-secundaria. Profesores universitarios Demostrar cinco o más años de experiencia como docente en cursos especializados de mediciones de software, o cursos relacionados de ingeniería de software en los que se enseñen temas de medición de software.

Haber publicado artículos sobre mediciones de software relacionados a sus áreas de interés de investigación.

Participar como miembro de un comité o asociación de mediciones de software en su país de origen o fuera de él (no obligatorio, pero preferible).

Tomando en consideración estos criterios, se elaboró una lista de posibles participantes a través de una búsqueda de artículos relacionados con mediciones de software en bibliotecas digitales como IEEE Xplore, Engineering Village, entre otras. Adicionalmente, se realizó una búsqueda de participantes en grupos especializados en mediciones de software existentes en LinkedIn, por ejemplo: Foro de Análisis y Medición; Mediciones de Software y Puntos de Función; Grupo de Usuarios del método COSMIC; entre otros.

La metodología seguida para llevar a cabo este estudio Delphi tomó como referencia los trabajos realizados por Okoli and Pawlowski (2004) [15] y Skulmoski et al. (2007) [17]. La Figura 1 muestra las mejoras realizadas a dicha metodología, entre estas: la separación de las actividades en tres grandes fases (preparación, ejecución y verificación); la inclusión de los procedimientos de aprobación por parte del comité de ética de la institución a cargo de llevar a cabo la investigación o entes reguladores de gobierno; y la inclusión de actividades de verificación de resultados. Como se puede apreciar en la figura, este estudio Delphi fue ejecutado en tres rondas. En cada ronda, una aplicación web estuvo disponible para recoger información de los participantes.

En la primera ronda, los expertos seleccionaron -de una lista de 13 tópicos de mediciones de software- cinco tópicos que (según su mejor criterio) deberían enseñarse en programas universitarios. La lista tomó en consideración 13 tópicos de medición incluidos en el cuerpo de conocimiento de mediciones de software [3] (los mismos tópicos que aparecen en la Tabla III más “Mediciones para el mantenimiento de software” y “Mediciones para la gestión de configuración de software”). Vale la pena mencionar que los tópicos fueron presentados en un orden aleatorio en cada una de las rondas.

Por cada tópico, los expertos debían identificar los niveles

de aprendizaje que los estudiantes de grado debían alcanzar en la universidad, escogiendo de entre una lista de enunciados. Por ejemplo, el tópico “Conceptos básicos de mediciones de software” contenía cinco enunciados de resultados de aprendizaje: Recordar terminología y conceptos; Dar ejemplos de conceptos básicos, métodos y procedimientos de medición; Explicar conceptos básicos; Usar terminología y conceptos en


121

Revisión de Literatura

Objetivo y Pregunta de investigación

Diseño general del Delphi

Selección de expertos

Diseño de la Ronda 1 del Delphi

Piloto Ronda 1

DelphiRonda 1


DelphiRonda 2

Presentación al comité de ética

Ajustes necesarios

Aprobado?

Resultados:Documentación

& Análisis

Encuesta para verificación

No

Si


DelphiRonda 3

Preparación

Ejecución

VerificaciónEntrevista con reconocidos expertos

Fig. 1. Vista General del estudio Delphi – adaptado de [15] y [17].

Un ejercicio o proyecto propuesto; y Diseñar/modificar procedimientos de medición. Para evitar sesgos, los participantes del estudio no conocían la relación entre los enunciados mostrados en la aplicación web y los seis niveles de aprendizaje de la taxonomía de Bloom –versión revisada por Anderson et al 2001. Los seis niveles de aprendizaje de esta versión de la taxonomía son: Recordar (R), Comprender (C), Aplicar (A), Analizar (Z), Evaluar (V) y Crear (E) [18].

Con los datos recopilados de cada panel (profesionales y profesores universitarios), se utilizaron los siguientes criterios para seleccionar los cinco tópicos de mediciones de software más importantes (que deberían ser incluidos en el currículo de programas de ingeniería de software):

Más del 50% de los participantes (profesores universitarios y profesionales) en ambos paneles eligió el tópico.

Más del 50% de los participantes (profesores universitarios o profesionales) de un panel escogió el tópico.

El tópico no alcanzó el nivel de aceptación del 50%, pero aun así fue calificado como uno de los 5 tópicos más importantes de ambos paneles.

Los participantes de los dos paneles estuvieron de acuerdo en seleccionar cuatro tópicos como relevantes. Sin embargo, el quinto tópico seleccionado en cada panel fue diferente, dando un total de seis tópicos que cumplían alguno de los criterios expuestos anteriores. Dichos tópicos son:

1. Conceptos básicos de mediciones de software (ambos paneles)

2. El proceso de medición (ambos paneles) 3. Técnicas y herramientas para mediciones de software

(ambos paneles) 4. Mediciones para la gestión de ingeniería de software

(ambos paneles) 5. Mediciones para la fase de requerimientos (panel de

profesionales) 6. Mediciones para la fase de diseño (panel de profesores)

Adicionalmente, en la primera ronda, los participantes seleccionaron los niveles de aprendizaje que - según ellos - los estudiantes de pregrado deberían de alcanzar para los cinco tópicos de medición de software considerados más importantes. Una aplicación web se desarrolló de tal manera que una vez que los participantes habían seleccionado los cinco tópicos más importantes, sus correspondientes niveles de aprendizaje aparecieran en la pantalla. Cada tópico tenía entre 4 y 6 enunciados que representaban los niveles de aprendizaje basados en la taxonomía de Bloom. Esto significa que cada nivel esperado de aprendizaje por tópico estaba asociado a un nivel de la taxonomía de Bloom. Los participantes no sabían la relación entre los niveles de aprendizaje que se mostraban en la pantalla con la taxonomía de Bloom. En el análisis de datos, se hizo uso de la relación para conocer qué niveles de aprendizaje de acuerdo a la taxonomía de Bloom fueron seleccionados por los participantes.

Una vez que los participantes seleccionaron los niveles de aprendizaje por tópico (los cinco más importantes), utilizamos los siguientes criterios para identificar la preferencia de los mismos:

Más del 50% de los participantes en ambos paneles eligió el nivel de aprendizaje.

Más del 50% de los participantes de un panel eligió el nivel de aprendizaje.

El nivel de aprendizaje no alcanzó más del 50% de aceptación, sin embargo, fue considerado como el más importante en ambos paneles.

Debido a la extensión de las tablas de niveles de aprendizaje, sólo se muestran en este artículo los resultados definitivos (ver Tabla IV – Niveles de aprendizaje por tópico).

En la segunda ronda, se pidió a los participantes ordenar los seis tópicos resultantes de la ronda 1 (los cuales fueron presentados de forma aleatoria en la aplicación web) de acuerdo a su importancia y que, además, dieran una explicación para justificar su ranking.

En la ronda 3 se presentaron los resultados del ranking obtenido y se les preguntó si estaban de acuerdo o no con la



122

lista de tópicos de mediciones de software considerados como prioritarios, posición que debían de argumentar obligatoriamente. Si no estaban de acuerdo, los participantes podían indicar su nuevo ranking.

Los criterios utilizados para determinar el ranking de los tópicos en las rondas 2 y 3 fue el siguiente:

La moda (la posición – del 1 al 6 - más comúnmente seleccionada por los participantes para un tópico específico)

El número de votos obtenidos por cada tópico. Con estos dos criterios, definimos un grado de consenso

(GC) entre los participantes, como se explica a continuación: Menos del 10% de los votos (0-9,99%): Muy débil grado de consenso (MD)

Menos del 30% de los votos (10 a 29,99%): Débil grado de consenso (D)

Menos del 50% de los votos (30 a 49,99%): Moderado grado de consenso (M)

Menos del 70% de los votos (50 a 69,99%): Fuerte grado de consenso (F)

Menos del 90% de los votos (70 a 89,99%): Muy fuerte grado de consenso (MF)

Menor o igual al 100% de los votos (90-100%): Extremadamente fuerte grado de consenso (EF)

Con una moda indeterminada: No hay consenso En la ronda 2 del panel de los profesores, logramos

identificar claramente el orden de las cuatro primeras posiciones del ranking de tópicos de mediciones de software. No obstante, las posiciones 5 y 6 no estaban claras. Por tanto, se requirió una tercera ronda para confirmar las cuatro primeras posiciones e identificar las posiciones 5 y 6.

Por otro lado, en la ronda 2 realizada con el panel de profesionales, identificamos las posiciones 1 y del 4 al 6. Es decir, que las posiciones 2 y 3 tuvieron un bajo nivel de consenso. La tercera ronda nos permitió identificar estas posiciones.

Con respecto a los niveles de aprendizaje por tópico, en la segunda ronda se evidenció un claro consenso entre los participantes, alcanzo grados de consenso considerados como fuerte, muy fuerte, extremadamente fuerte. Por tal razón, los niveles de aprendizaje por tópico no fueron incluidos en la ronda 3.

Los criterios utilizados para determinar las preferencias de los participantes con respecto a los niveles de aprendizaje fueron:

Menos del 10% de los votos (0-9,99%): preferencia muy débil (MD)

Menos del 30% de los votos (10 a 29,99%): preferencia débil (D)

Menos del 50% de los votos (30 a 49,99%): preferencia moderada (M)

Menos del 70% de los votos (50 a 69,99%): preferencia fuerte (F)

Menos del 90% de los votos (70 a 89,99%): preferencia muy fuerte (MF)

Menor o igual a 100% de los votos (90-100%): preferencia extremadamente fuerte (EF)

La tabla IV muestra los niveles de aprendizaje por tópico que fueron seleccionados por los participantes. Como se puede notar, los tres primeros niveles correspondientes a la Taxonomía de Bloom son los más preferidos (R, C y A) - ver tercera columna de la tabla IV.

TABLA IV. TEMAS SUGERIDOS Y NIVELES DE APRENDIZAJE DE ACUERDO AL ESTUDIO DELPHI

Tópicos Niveles de Aprendizaje por Tema Nivel de Bloom

Recordar terminología y conceptos R

Dar ejemplos de conceptos básicos, métodos y procedimientos de medición C

Explicar conceptos básicos C

#1 Conceptos básicos de

mediciones de software

Usar terminología y conceptos en un ejercicio o proyecto propuesto A

Recordar el proceso de medición R #2 El proceso de

medición Usar el proceso de mediciones en un proyecto o situación dado. A

Recordar las técnicas y herramientas de medición de software existentes R

Explicar las técnicas y herramientas de medición de software C

#3 Técnicas y

herramientas para mediciones

de software Usar una técnica en un ejercicio o proyecto A

Recordar conceptos relacionados a estimación de esfuerzo y medidas para planeación y control de proyectos

R

Explicar cómo estimar el esfuerzo de un proyecto C

#4 Mediciones para la gestión de la ingeniería de

software Medir el tiempo y esfuerzo en un proyecto A

Recordar los métodos más comunes de medición de tamaño funcional R

Interpretar cómo trabajan los métodos de medición de tamaño funcional C

#5 Mediciones para

la fase de requerimientos

Obtener el tamaño funcional de software en un ejercicio o proyecto siguiendo un método de medición

A

Por propósitos de generalización, efectuamos una verificación de resultados por medio de:

Una encuesta realizada a profesores universitarios y profesionales de la rama que asistieron a conferencias de ingeniería de software llevadas a cabo en Septiembre, Octubre y Noviembre del 2012 [5]; y

Entrevistas con escritores de libros de medición de software [5].

Los asistentes a las conferencias, que voluntariamente contestaron el cuestionario de verificación de resultados del Delphi, debían indicar su grado de acuerdo con los resultados obtenidos mediante el uso de una escala de Likert de cinco puntos (Muy en desacuerdo; en desacuerdo; Neutral; de acuerdo; y Muy de acuerdo). Es importante anotar que dos de los seis tópicos (Técnicas y Herramientas y Mediciones para la Fase de Requerimientos) obtuvieron porcentajes menores de acuerdo. Es decir, que las respuestas obtenidas fueron De acuerdo y Muy de acuerdo; a diferencia de los otros tópicos que obtuvieron Muy de acuerdo. Las razones dadas por los profesionales para justificar su selección han sido resumidas a continuación:

La fase de requerimientos es la que impacta más fuertemente en el éxito del proyecto. Todos los problemas comienzan con requisitos pobres. Los estudiantes de carreras ligadas a las tecnologías de la información deben estar convencidos de que estudiar este tema es más importante que aprender sobre técnicas y herramientas.


123

Las mediciones de la fase de requerimientos son usadas para las mediciones de la gestión, por tanto, las de requerimientos deben de aprenderse antes.

Los estudiantes deben saber primero cuáles son las mediciones específicas antes de seleccionar herramientas. Las mediciones te indican “qué” medir y las herramientas “cómo” hacerlo.

Las mediciones para el diseño son muy específicos; por tanto, son adecuados para estudiantes de maestría.

Las mediciones de puntos de función -usadas en la fase de requerimientos- requieren tiempo para ser aprendidas, sería más conveniente que se enseñen a estudiantes de maestría y no de pregrado.

Con relación a los niveles de aprendizaje seleccionados por los participantes de la encuesta, se detectaron discrepancias; especialmente con respecto al tópico de Mediciones para la Fase de Diseño. Se evidenció que este tema es generalmente preferido por los profesores universitarios, pero no por los profesionales. Los resultados indican que aparentemente los profesores esperan que sus estudiantes apliquen la teoría mediante la puesta en prácticas de las mediciones de diseño (Ej: cohesión y acoplamiento); probablemente porque los estudiantes de pregrado están más familiarizados con tareas de diseño y programación.

Como se mencionó en la página anterior, por fines de verificación se entrevistaron escritores de libros de mediciones de software, cuatro autores en total. Durante la entrevista - 40 minutos en promedio, se les preguntó acerca de sus opiniones con respecto a los resultados obtenidos en el estudio Delphi. Ellos tenían la libertad de hacer comentarios y argumentar su acuerdo o desacuerdo con los resultados del Delphi, ya que la entrevista fue de tipo semiestructurada. Este tipo de entrevistas, se caracterizan por [19, 20]:

Tener una guía de la entrevista (lista de preguntas que deben ser contestadas);

Ser flexibles (cambiar el orden o añadir preguntas según el curso de la entrevista);

Dar explicaciones con relación a las preguntas y pedir aclaraciones si la respuesta no es clara;

Usar palabras apropiadas de acuerdo a la situación; Usar un estilo conversacional, pero manteniendo el enfoque en la guía.

En general, las opiniones recopiladas en las entrevistas, indican que los autores de los libros están de acuerdo con los resultados del Delphi, ya que el orden de los tópicos resultó ser el mismo; aunque, ellos manifestaron algunos desacuerdos que se presentan a continuación.

Uno de los autores mencionó que las mediciones de gestión de software se les debe enseñar después de las mediciones específicas (Ej: de requerimientos y de diseño). Comentó que el ranking de los tópicos resultantes del Delphi está lógicamente ordenado desde el punto de vista de los profesionales que trabajan en organizaciones que ya tienen datos históricos para realizar sus estimaciones. Dijo que éste no es el caso de los estudiantes de pregrado, porque están en el proceso de aprendizaje de la medición del software, por lo que deberían aprender primero en la fase de requerimientos.

Otro autor indicó que el ubicaría al tópico de mediciones de gestión de software en segundo lugar ya que considera que los estudiantes necesitan saber primero por qué necesitamos hacer mediciones específicas para obtener mediciones de gestión.

Otro autor dijo que estaba de acuerdo con los tópicos seleccionados como prioritarios, a excepción de las mediciones para la fase de diseño, ya que piensa que este tópico no debería ser una prioridad. Según él, sólo los primeros cinco tópicos en el ranking deben ser considerados como obligatorios para los estudiantes universitarios.

Dos autores sugirieron que la importancia de la medición del software debe ser fuertemente enfatizada. Uno de ellos también recomendó que se vincule la importancia de las mediciones con tener objetivos claros para medir el software; así como darles a conocer las consecuencias de no realizar mediciones. Por último sugirió que la academia debe buscar maneras para motivar a los estudiantes a medir.

Las opiniones de los entrevistados en relación a los niveles de aprendizaje que los estudiantes deben alcanzar por cada tópico priorizado fueron de alguna manera similares a los obtenidos en el estudio Delphi y en las encuestas realizadas en la fase de verificación. Esto significa que, los expertos -en su mayoría- eligieron los niveles de aprendizaje que corresponden a los primeros niveles de la taxonomía de Bloom (Recordar, Comprender y Aplicar). Sin embargo, se observaron las siguientes diferencias:

En el caso de las mediciones para la fase de diseño, todos los entrevistados coinciden en que los estudiantes universitarios sólo deberían alcanzar los dos primeros niveles de aprendizaje (recordar y entender).

Un entrevistado considera que los estudiantes de pregrado no deben alcanzar el nivel de aprendizaje Aplicar para los dos tópicos siguientes: Proceso de Medición, y Técnicas y Herramientas. Es decir, los estudiantes no deberían utilizar un proceso de medición en un proyecto, ni usar técnicas de medición en un ejercicio o proyecto. Mientras que otro entrevistado manifestó su desacuerdo en que los estudiantes realicen mediciones del tamaño de los requerimientos funcionales del software. Según estos expertos (ambos con experiencia en docencia universitaria), los maestros pueden enfrentar restricciones de tiempo al tratar de hacer frente a los niveles más altos de aprendizaje (desde el nivel aplicar hasta el nivel crear). Además, uno de los expertos dijo que los tópicos Proceso de Medición, y Técnicas y Herramientas son dependientes del contexto. Por lo tanto, llegar al nivel de comprensión de estos temas puede ser suficiente para los estudiantes de pregrado.

Para resumir esta sección, podemos decir que los resultados del estudio Delphi sugieren indicar que cinco tópicos de mediciones de software son altamente recomendados para ser enseñados a los estudiantes de pregrado. La primera columna de la Tabla IV muestra estos temas en el orden de prioridad que obtuvieron en el estudio.

De las Tablas III y IV, se puede observar que el orden de estos tópicos concuerda de alguna manera con la preferencia de tópicos identificada en la encuesta vía web administrada a profesionales (ver literal A de la sección III). En otras palabras, cuatro tópicos definidos como prioritarios en el estudio Delphi aparecen entre los cinco primeros tópicos seleccionados por los profesionales que participaron en la encuesta web.

La segunda columna de la tabla IV muestra los niveles de aprendizaje -por tema- que alcanzaron un alto porcentaje de preferencia entre los expertos (más del 70%). Esto es, los niveles de aprendizaje que los estudiantes de pregrado



124

necesitan alcanzar. En la Tabla IV, el mapeo entre los enunciados del cuestionario y la taxonomía de Bloom aparecen a la derecha (R: Recordar; C: Comprender; A: Aplicar). Cabe mencionar que el cuestionario usado en la primera fase de este estudio incluyó enunciados que cubrían los seis niveles de aprendizaje de la taxonomía de Bloom; no obstante, solo tres de éstos fueron seleccionados por los participantes (R, C y A) y pasaron a otras fases.

IV. SUGERENCIAS PARA UN CURRÍCULO DE INGENIERIA DE SOFTWARE

La información recogida de las secciones 2 y 3 fue usada como dato de partida para identificar mejoras a tomarse en cuenta para la revisión y actualización de los lineamientos del currículo de ingeniería de software a nivel de pregrado. Las mejoras sugeridas son las siguientes:

A. Estandarización de las áreas de conocimiento En el mapeo realizado entre las directrices curriculares

(SE2004), el Cuerpo de Conocimiento de mediciones de software y la guía SWEBOK, observamos que las áreas de conocimiento (denominados como tópicos en el Cuerpo de Conocimiento de Mediciones de software) tienen un contenido similar pero utilizan nombres diferentes. Por lo tanto, nuestra primera recomendación es la de usar el mismo nombre de un área de conocimiento para todos los cuerpos de conocimiento. Sugerimos, además, que el nombre de cada área sea el que utiliza el SWEBOK v3, ya que es el documento a partir del cual se desarrollaron los otros cuerpos de conocimiento y guías curriculares. Por ejemplo:

Se debería usar como nombre Requerimientos de Software (SWEBOK v3.0) en lugar de Modelamiento y Análisis de Software (SEEK –SE2004)

Se debería usar Pruebas de Software en vez de Verificación y Validación de Software.

Consideramos que esta estandarización de nombres facilitará el trabajo de voluntarios y otras personas que hacen uso de los Cuerpos de Conocimiento para diseño de currículos y otros propósitos.

B. Versiones de la taxonomía de Bloom En nuestra revisión de las directrices curriculares SE2004,

observamos que los niveles de aprendizaje incluidos en dicho documento están basados en la versión original de la taxonomía de Bloom [4]. A este respecto, recomendamos usar la versión actualizada de esta taxonomía publicada por Anderson et al en 2001 [18]. En esta versión actualizada, los nombres de los niveles de aprendizaje fueron cambiados de sustantivos a verbos. Por ejemplo: de Conocimiento a Recordar; de Comprensión a Comprender; de Aplicación a Aplicar; y así sucesivamente. Todos los estudios resumidos en este artículo han usado la versión actualizada.

C. Centrarse en prioridades En las directrices curriculares SE2004, todos los temas

relacionados a medición de software incluidos en SEEK son considerados esenciales (E) – Ver tabla V, columna R de las Guías curriculares vigentes. Sin embargo, el trabajo de investigación -resumido en la sección III de este artículo- revela que existen prioridades en este campo; las mismas que deberían tomarse en cuenta al momento de preparar cursos universitarios relacionados a mediciones de software.

Basándonos en los hallazgos de los estudios realizados, especialmente aquellos del estudio Delphi, consideramos que los cinco tópicos prioritarios son aquellos que deberían

considerarse como esenciales (E) en las nuevas directrices curriculares para programas de pregrado de ingeniería de software. Estos tópicos, al ser menos numerosos, pueden ser profundizados con los estudiantes para alcanzar los niveles de aprendizaje esperados. Este planteamiento involucra la re-conceptualización de las directrices curriculares, la misma que debería enfocarse en la profundización de los tópicos prioritarios en lugar de cubrir contenidos extensos (muchos tópicos). Consideramos, además, que los tópicos propuestos como deseables (D) para estudiantes de pregrado, bien podrían considerarse como esenciales para estudiantes de posgrado.

Nuestra sugerencia para formular una nueva versión de las directrices curriculares para programas de pregrado de Ingeniería de Software –en lo que respecta únicamente a tópicos relacionados a mediciones de software- se muestra en la tabla V. En dicha tabla, se presentan: las áreas de conocimiento (tomadas de SWEBOK v3.0); las unidades de conocimiento sugeridas; los tópicos de mediciones de software, los niveles de aprendizaje (N) y la relevancia de cada tópico (R). Es importante anotar, que en dicha tabla aparece un total de siete tópicos: cinco considerados como prioritarios de acuerdo a los resultados expuestos en la sección III y dos (Diseño de Software y Calidad del Software) que captaron una atención considerable de los profesionales encuestados.

A los cinco tópicos prioritarios se les asignó una relevancia E (Esencial) y a los dos restantes D (Deseable). Asimismo, es importante indicar que los niveles de aprendizaje mostrados en la Tabla V sólo corresponden a los niveles más altos seleccionados por los participantes del estudio Delphi. Por ejemplo, para el tema #1 – Conceptos Básicos de Mediciones de Software, los participantes escogieron tres niveles de aprendizaje (Recordar, Comprender y Aplicar); por lo tanto, la Tabla V sólo presenta el nivel más alto (Aplicar).

De acuerdo a la Tabla V, tres consideraciones deben tomarse en cuenta para formular nuevas directrices curriculares: 1) La inclusión del tema de Medición del Tamaño Funcional

en el área de conocimiento Requerimientos de Software. Las guías curriculares vigentes (SE2004) mencionan este tema como parte del curso SE323 Gestión de Proyectos de Software sugerido en los lineamientos [2]. Sin embargo, este tema no aparece en la tabla asociada al SEEK donde se sugieren los temas, niveles de aprendizaje y relevancia para estudiantes de grado.

2) La revisión del tema Métricas de Diseño. Este tipo de mediciones (por ejemplo, factores arquitectónicos) no esté presente en el área de conocimiento de Diseño de Software del SWEBOK v3.0 ni tampoco en el Cuerpo de conocimiento de Mediciones de Software. Por consiguiente, sugerimos que se haga una revisión de dicha área de conocimiento para determinar el contenido a ser incluido en los cuerpos de conocimiento; y así mismo determinar si éste es apropiado para los estudiantes de pregrado o posgrado. Nuestro estudio no incluyó este tema en la lista de ejemplos de tópicos de medición que los participantes debían escoger, ya que tomamos como referencia el cuerpo de conocimiento de mediciones de software y SWEBOK v3.0. Entre los ejemplos que presentamos a los participantes, sólo incluimos el tema Mediciones de Atributos de Diseño (por ejemplo: acoplamiento, cohesión, etc.) que si se encuentra en los cuerpos de conocimientos antes mencionados.


125

TABLA V. SUGERENCIAS PARA ELABORAR NUEVAS DIRECTRICES CURRICULARES

Guías curriculares vigentes (SEEK del SE2004)

SUGERENCIAS para actualizar las directrices curriculares de ingeniería de

software basadas en SWEBOK v3.0

Areas de Conocimiento (tomadas de SWEBOK

v3.0)

Unidades de conocimiento (sugeridas)

Tópicos N R Tópicos N R

Métricas y mediciones K E Fundamentos de Matemáticas e Ingeniería

Fundamentos de Ingeniería para el

Software Teoría de mediciones C E

Conceptos básicos de mediciones de softare (definición, unidades,

escalas, etc) A E

Requerimientos de Software

Mediciones de requerimientos de

software No encontrado en SEEK Medición de talla funcional (qué

es?, métodos) A E

Mediciones de atributos del diseño (ej. Acoplamiento,

cohesión,etc.) K E Mediciones de diseño (orientadas

a objetos y a funciones) U D Diseño de Software

Análisis y evaluación de la

calidad del diseño Métricas de diseño (ej. Factores arquitectónicos,

interpretación, etc.) A E No encontrado en SWEBOK v3.0 (se sugiere

una revisión)

Medición y análisis de procesos de software C E

Análisis y control de la calidad (ej. Prevención de

defectos, métricas de calidad, análisis de causa

raíz, etc.)

C E

Proceso de software individual (modelo,

definición, mediciones, análisis, mejora)

C E

Proceso de Ingeniería de Software

Técnicas de medición de procesos de

software

Procesos de software en equipos (modelo, definición,

organización, mediciones, análisis, mejora)

C E

Introducción a técnicas y modelos de medición de procesos de

software (análisis de causa-raíz, mejora y evaluación de procesos, ejemplos de modelos y métodos

para procesos de software)

A E

Modelos y métricas de calidad del Software C E


Mediciones de la calidad del software Métricas y mediciones de la

calidad del producto C E

Medición de la calidad del software (el costo de la calidad,

estándares y modelos relacionados que incluyen mediciones -Ej.

ISO/IEC/IEEE12207 and CMMI)

R D

Planificación de proyectos de

software Estimación de esfuerzo A E Estimación de esfuerzo A E

Medición y análisis de resultados A E Medición y análisis de resultados U D

Gestión de la Ingeniería de

Software Mediciones en ingeniería de

software No encontrado en SEEK El proceso de medición A E

3) La inclusión del tema Proceso de Medición dentro del

área de conocimiento Gestión de Ingeniería la de Software. Este tema no fue considerado en ninguna de las áreas de conocimiento del SE2004.

V. CONCLUSIONES Este artículo presenta recomendaciones a ser consideradas

para actualizar las directrices del currículo de ingeniería de software para programas de pregrado basadas en el análisis de los cuerpos de conocimiento, los lineamientos curriculares existentes y las aportaciones de profesores universitarios y profesionales de la ingeniería de software en ejercicio.

Primero, el análisis de los cuerpos de conocimiento revela una presencia significativa de temas de medición de software dentro de sus áreas de conocimiento (KAs). De hecho, la última versión de SWEBOK v3.0 contiene temas de medición en 11 de sus KAs.

Segundo, los resultados de la encuesta realizada vía web y del estudio Delphi permitieron formular recomendaciones para el desarrollo de nuevas directrices curriculares para programas de pregrado en ingeniería de software. Las recomendaciones abarcan la inclusión de temas esenciales de medición de software que deben estar presentes en los nuevos lineamientos



126

curriculares, así como sus correspondientes niveles de aprendizaje y relevancia.

Los autores de este artículo sostenemos que estas recomendaciones son útiles para ayudar a los profesores universitarios en la selección de temas de medición de software que deben priorizarse en los cursos de pregrado que ellos imparten. También sostenemos que la metodología aplicada en este trabajo de investigación puede ser valiosa para diseñadores de currículos e investigadores que se enfocan en temas educacionales.

Finalmente, una implicación práctica es que la metodología utilizada en este estudio puede aplicarse no sólo en investigaciones relacionadas a la enseñanza de mediciones de software, sino también en cualquier ciencia o campo de la ingeniería. Esto es factible ya que la metodología proporciona un enfoque bien estructurado para identificar prioridades en cualquier ámbito del conocimiento.

REFERENCIAS [1] P. Bourque and R. Fairley, SWEBOK : Guide to the Software

Engineering Body of Knowledge: IEEE Computer Science, 2014.

[2] IEEE ACM. (2004, Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering. SE2004 Volume – 8/23/2004, 135. Available: http://sites.computer.org/ccse/SE2004Volume.pdf

[3] A. Abran, A. April, and L. Buglione. (2010, 26 January 2011). Software Measurement Body of Knowledge. Encyclopedia of Software Engineering 1:1(1), 1157 — 1168.

[4] B. Bloom, Taxonomy of educational objectives the classification of educational goals, First edition ed. New York Green Longmans, 1956.

[5] M. Villavicencio, "Development of a framework for the education of software measurement in software engineering undergraduate programs," Ph. D., Software Enginnering and Information Technology, École de technologie supérieure, Montreal, 2014.

[6] P. Bourque, A. Abran, J. Garbajosa, G. Keeni, and B. Shen. (2008, October 15, 2010). SWEBOK Version 3. 18. Available: http://www2.computer.org/cms/Computer.org/SWEBOK/MeasurementKA-Draft-Feb2008.pdf

[7] M. Villavicencio and A. Abran, "The Necessary Software Measurement Knowledge in Software Engineering Education from the Practitioners' Point of View," in 25th IEEE Canadian Conference on Electrical and Computer Engineering (CCECE) Montreal, 2012.

[8] T. Amos and N. Pearse, "The delphi technique and educating entrepreneurs for the future," in 7th European Conference on Research Methodology for Business and Management Studies, ed: Academic Publishing Limited, Reading, UK 2008 2008, pp. 17-24.

[9] D. W. Gatchell, R. A. Linsenmeier, and T. R. Harris, "Determination of the core undergraduate BME curriculum - the 1st step in a Delphi study," in Conference Proceedings. 26th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, 1-5 Sept. 2004, Piscataway, NJ, USA, 2004, pp. 5200-1.

[10] P. Howze and C. Dalrymple, "Consensus without all the meetings: using the Delphi method to determine course content for library instruction," Reference Services Review, vol. 32, pp. 174-84, 2004.

[11] H.-L. Hung, J. W. Altschuld, and Y.-F. Lee, "Methodological and conceptual issues confronting a cross-country Delphi study

of educational program evaluation," Evaluation and Program Planning, vol. 31, pp. 191-198, 2008.

[12] J. Lambeth, R. Joerger, and J. Elliot, "Implications for Focusing Research in Career and Technical Education and Workforce Development," Career and Technical Education Research, vol. 34, pp. 137-153, 2009.

[13] P. Bourque, R. Dupuis, A. Abran, J. W. Moore, L. Tripp, and S. Wolff, "Fundamental principles of software engineering - a journey," Journal of Systems and Software, vol. 62, pp. 59-70, 2002.

[14] E. Hall, "The Delphi Primer: Doing Real-World or Academic Research Using a Mixed-Method Approach," in The Refractive Thinker®: Vol II Research Methodology vol. 2, ed: The Lentz Leadership Institute, 2009, pp. Kindle Locations 103-104.

[15] C. Okoli and S. D. Pawlowski, "The Delphi method as a research tool: an example, design considerations and applications," Information & Management, vol. 42, pp. 15-29, 2004.

[16] R. C. Schmidt, "Managing Delphi Surveys Using Nonparametric Statistical Techniques*," Decision Sciences, vol. 28, pp. 763-774, 1997.

[17] G. J. Skulmoski, F. T. Hartman, and J. Krahn, "The Delphi Method for Graduate Research," Journal of Information Technology Education, vol. 6, pp. 1-21, 2007.

[18] L. Anderson, D. Krathwohl, P. Airasian, K. Cruikshank, R. Mayer, P. Pintrich, et al., A taxonomy for learning, teaching and assessing. A revision of Bloom's taxonomy of Educational Objectives. New York: Addison Wesley Longman, Inc, 2001.

[19] A. Bhamani Kajornboon. (2005, Using interviews as research instruments. 10. Available: www.culi.chula.ac.th/e-journal/bod/annabel.pdf

[20] P. Leedy and J. E. Ormrod, Practical research: planning and design, Ninth edition ed.: Pearson, 2010.

Mónica Villavicencio. Obtuvo su doctorado en Ingeniería de Software (2014) en la École de Technologie Supérieure ETS -Université du Québec (Montreal, Canadá). Ella es profesora titular en la Escuela Superior Politécnica del Litoral (ESPOL) en Guayaquil, Ecuador donde imparte cursos de ingeniería de software para los

programas de pregrado y postgrado. Sus intereses de investigación son: mejora de procesos de software, mediciones de software, gestión de proyectos de software y calidad de software.

Alain Abran. Tiene un doctorado en Ingeniería Eléctrica y Computación (1994) de la École Polytechnique de Montréal (Canadá). El es profesor en la École de Technologie Supérieure (ETS) - Universidad de Quebec (Montreal, Canadá). Tiene más de 20 años de experiencia en la industria de desarrollo de sistemas de información e ingeniería de software. Sus intereses

de investigación son: Modelos de estimación, fundamentos de la ingeniería de software, medición del tamaño funcional del software, gestión de riesgos y mantenimiento de software.

Moisés Rodríguez, Óscar Pedreira y Carlos M. Fernández. 2015. Certificación de la Mantenibilidad del Producto Software: Un Caso Práctico Revista Latinoamericana de Ingeniería de Software, 3(3): 127-134, ISSN 2314-2642

127

Certificación de la Mantenibilidad del Producto Software: Un Caso Práctico

Moisés Rodríguez Alarcos Quality Center, Universidad de

Castilla-La Mancha Ciudad Real, España

[email protected]

Óscar Pedreira Laboratorio de Base de Datos,

Universidad de la Coruña A Coruña, España

[email protected]

Carlos Manuel Fernández AENOR, Asociación Española de

Normalización y Certificación Madrid, España

[email protected]

Resumen— La calidad del software está adquiriendo durante

los últimos años una gran importancia, principalmente debido a que el software está presente en prácticamente todo lo que nos rodea y se hace necesario asegurar su correcto funcionamiento. Sin embargo, hasta ahora la mayor parte de los estudios se han centrado en evaluar la calidad de los procesos de desarrollo, y aunque existen trabajos centrados en la calidad del producto software, no existe todavía una propuesta completa para la evaluación y certificación de la calidad del producto software, basada en la nueva familia de normas ISO/IEC 25000. El presente artículo expone un caso de estudio de evaluación, mejora y certificación de la mantenibilidad de un producto software, en el que han participado una empresa desarrolladora de software, un laboratorio de evaluación acreditado y una entidad de certificación. Para ello, se presentarán las características de este tipo de evaluaciones, el rol que cumple cada una de las entidades participantes y el proceso seguido desde la evaluación inicial hasta la certificación definitiva.

Palabras Clave— ISO/IEC 25000, calidad producto software, certificación, laboratorio acreditado, mantenibilidad, modelo de calidad.

I. INTRODUCCIÓN Hoy en día el software está en prácticamente todo lo que

nos rodea, no solo en ordenadores, móviles o tablets, sino en los electrodomésticos, en los vehículos, en el sector de la medicina, en la banca y seguros, etc. Este aumento en la demanda de productos software ha dado lugar a un crecimiento de las empresas y departamentos encargados de su desarrollo, lo que se conocen como “software factories” [1]. Por otro lado, la falta de personal especializado para ciertas tareas del desarrollo software, así como la búsqueda de la reducción de costes han dado lugar a lo que se conoce como “outsourcing” del desarrollo software, de manera que las empresas externalizan todo o parte de las actividades de desarrollo software a otros departamentos o empresas. Sin embargo, cuando se externaliza aumentan los riesgos y la falta de control sobre la calidad del software que la empresa contratada entrega, surgiendo la necesidad de evaluar y asegurar la calidad del software de dichas empresas.

Aunque desde hace bastantes años la evaluación de la calidad del software es un campo de gran actividad tanto investigadora como en el sector industrial, la mayor parte del esfuerzo realizado se ha centrado en la calidad de los procesos, habiéndose desarrollado gran cantidad de modelos y estándares de referencia, evaluación y mejora de procesos software: ISO 90003, ISO 12207, ISO 15504, CMM, CMMI, IDEAL, SCAMPI, etc., en los que numerosas empresas de todo el mundo se han evaluado y/o certificado. Sin embargo, es cada día mayor el número de organizaciones y empresas que se

interesan, no solo por la calidad de los procesos que se siguen en el desarrollo de software, sino también por la calidad de los productos que desarrollan y/o adquieren, ya que una vez que el producto ha sido implantado en sus instalaciones se encuentran con graves problemas de calidad y complicaciones a la hora de corregirlo, adaptarlo o evolucionarlo [2].

Desde hace varias décadas se han elaborado también trabajos de investigación, normas y estándares, con el objetivo de crear modelos, procesos y herramientas de evaluación de la calidad del propio producto software. Entre los más representativos podemos citar: [3-6] y la nueva familia de normas ISO/IEC 25000 [7]. Sin embargo, la certificación de la calidad del producto software sigue siendo a día de hoy un área relativamente joven de la Ingeniería del Software, en la que todavía no existe un consenso definitivo.

Por este motivo y con el objetivo de conocer los trabajos existentes sobre certificación de la calidad del producto software, en 2012 se realizó la revisión sistemática expuesta en [8] siguiendo la guía propuesta por Kitchenham en [9], junto con la plantilla descrita por Biolchini en [10]. Como resultado se obtuvo un conjunto de 10 estudios primarios que cumplían con los requisitos de búsqueda, reflejados en la Tabla 1.

TABLA I. LISTADO DE ESTUDIOS PRIMARIOS SELECCIONADOS

Id Título Año Referencia

1 A software product certification model 2010 [11]

2 Embedded software component quality and certification 2009 [12]

3 Performance certification of software components 2011 [13]

4 Requirements certification for offshoring using LSPCM 2010 [14]

5 SCfM_PROD: A software product certification model 2008 [15]

6 Continuously ensuring quality through software product certification: A case study 2010 [16]

7 A Software Certification Consortium and its Top 9 Hurdles 2009 [17]

8 Software component certification 2001 [18]

9 Standardized code quality benchmarking for improving software maintainability 2011 [19]

10 Towards a software component certification framework 2007 [20]

Entre las principales conclusiones obtenidas se pueden destacar las siguientes:

La mayoría de los estudios destacan el trabajo que ya existe en la certificación de procesos de desarrollo software y la necesidad de que esta certificación sea también extendida a las características del producto.


128

La mayoría de los estudios se basan en características de calidad extraídas de normas internacionales como la ISO/IEC 9126, utilizando métodos de evaluación también estándares como los de la ISO/IEC 14598. Sin embargo, ninguna de las propuestas ha adoptado el nuevo modelo y proceso de la familia ISO/IEC 25000.

Aunque ya existen varias propuestas para certificar el producto software, la mayoría de ellas carece o tiene un número reducido de aplicaciones reales en la industria del software.

La mayoría de los estudios utiliza indistintamente los conceptos de evaluación y certificación, lo que se considera un error. Es necesario diferenciar entre el proceso de evaluación, realizado frente a un modelo de calidad, y el posterior proceso de certificación realizado por un organismo acreditado e independiente.

Un denominador común de los estudios que presentan casos de aplicación práctica es la importancia que atribuyen a disponer de una herramienta que automatice las actividades.

Por todo lo anterior, el objetivo del presente artículo es presentar las características principales de una propuesta completa para la evaluación y certificación del producto software basadas en la familia ISO/IEC 25000 y demostrar su aplicación mediante un caso de estudio práctico. Para ello, el resto del artículo se estructura de la siguiente manera: en el apartado 2 se presenta el modelo de AENOR (Asociación Española de Normalización y Certificación) para Gobierno de las TICs basado en estándares ISO, dentro del cual se ha incluido la nueva familia de normas ISO/IEC 25000. En el apartado 3 se resumen los principales elementos de la evaluación, haciendo especial hincapié en el ecosistema de evaluación y en el laboratorio acreditado AQC Lab. En el apartado 4 se presenta el flujo de trabajo que se sigue para la certificación del producto una vez ha sido evaluado por un laboratorio acreditado, así como los resultados de un caso práctico de evaluación, mejora y certificación de un producto software. Y finalmente, el apartado 5 presenta las conclusiones obtenidas con este trabajo y las líneas futuras de investigación.

II. MODELO DE AENOR PARA TICS CON ESTÁNDARES ISO Desde al año 2006, AENOR ha presentado y desarrollado

un modelo de Gobierno y Gestión de las TIC para el siglo XXI (Fig. 1) basado en normas ISO [21] con las mejores prácticas del sector. Este modelo ha tenido una gran aceptación en el mundo empresarial público y privado, debido a que está orientado a la mejora de la productividad, la innovación y el ahorro de costes; con una especial directriz que cumple con los objetivos de las organizaciones.

Básicamente, el modelo propone dos grandes áreas y tres certificaciones. El área de producción diaria de un Centro de Procesamiento de Datos (CPD), con los objetivos de calidad y seguridad de los servicios de TI (ISO/IEC 20000-1 e ISO 27001); y el área de ingeniería o desarrollo del software con calidad y madurez en sus procesos con SPICE ISO 15504 -ISO 12207. Como características de este modelo hay destacar las siguientes:

Es un modelo avalado por más de 150 países que han participado en el desarrollo e implantación de los estándares ISO que en él se recogen. Esto demuestra la madurez e importancia que el modelo y las normas en las que se apoya tienen dentro del sector de las TICs.

Es un modelo dinámico, puesto que se encuentra en constante evolución, tanto por los avances que van

saliendo en la industria de las TICs y que son incluidos en el mismo, como por las nuevas versiones de los estándares que lo forman que igualmente son adaptadas y consideradas.

Fig. 1. Modelo de AENOR para Gobierno y Gestión de las TICs con

estándares ISO [22]

Recientemente y después de un período de maduración y consolidación del modelo, en especial en el área de desarrollo de software o factorías de software, se ha considerado oportuno asumir una nueva certificación según la Norma ISO/IEC 25000 de producto software. En un principio centrada en una de las características, la mantenibilidad, para continuar próximamente con otras características de la propia ISO/IEC 25000.

De manera básica pero ilustrativa, lo que se pretende con este nuevo certificado de producto software es algo equivalente a lo que representa el sello EuroNCAP (European New Car Assessment Programme) en la industria del automóvil. Es decir, igual que cuando compramos un vehículo queremos que haya sido revisado y tenga las máximas estrellas EuroNCAP, este nuevo certificado permite conocer la calidad de los productos software en base a una norma internacional como es la ISO/IEC 25000 y poder optar por la opción que mejor se adecua a nuestras necesidades

III. EVALUACIÓN DE LA CALIDAD DEL PRODUCTO Una vez presentado el modelo de AENOR para gobierno de

las TICs basado en normas ISO, en el presente apartado se detallarán los elementos necesarios para llevar a cabo la evaluación de la calidad del producto software.

A. Familia de normas ISO/IEC 25000 La familia de normas ISO/IEC 25000 tiene por objetivo la

creación de un marco de trabajo común para evaluar la calidad del producto software, sustituyendo a las anteriores ISO/IEC 9126 e ISO/IEC 14598 y convirtiéndose así en la piedra angular de esta área de la Ingeniería del Software. La familia ISO/IEC 25000 se encuentra compuesta de varias partes o divisiones, entre las que podemos destacar:

La norma ISO/IEC 25010 [23] que define varios modelos de calidad y determina las características de calidad del producto software que se pueden evaluar (Fig. 2). En total son 8 las características de calidad que identifica:


129

Fig. 2. Modelo de calidad del producto software según la ISO/IEC 25010

funcionalidad, rendimiento, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad. Esta parte de la norma representa por tanto el espejo frente al cual podemos mirar la calidad de nuestro producto software.

La norma ISO/IEC 25040 [24] que define el proceso de evaluación, compuesto por cinco actividades, que determinan las tareas a realizar para poder evaluar la calidad del producto software: Establecer los requisitos, Especificar la evaluación, Diseñar la evaluación, Ejecutar la evaluación y Concluir la evaluación.

La norma ISO/IEC 25020 que será la encargada de definir las métricas de calidad del producto software y que todavía está en pendiente de publicación.

B. Requisitos para la evaluación y certificación del producto A partir de todo lo anterior, se pueden extraer los requisitos

principales para poder llevar a cabo la evaluación y certificación de la calidad del producto software, que además de personal experimentado, se pueden concretar en los siguientes tres elementos: un modelo de calidad, un proceso de evaluación y un entorno tecnológico que de soporte a los dos elementos anteriores.

1) Modelo de Calidad El objetivo del modelo es definir las características del

producto software que se pue-den evaluar y que por tanto influyen en la calidad del mismo, es decir, el modelo deja claro los puntos de vista desde los que se puede considerar la calidad de un producto software. Es importante remarcar que el modelo define el qué evaluar (características de calidad), pero no el cómo evaluarlas. Aspectos como la funcionalidad que tiene un producto, la usabilidad, la seguridad o la mantenibilidad del producto software podrían ser algunos de estos tipos de características.

Es importante que el modelo no solo defina las características de calidad, sino que también desglose éstas en subcaracterísticas de más bajo nivel y a su vez estas en indicadores y métricas que se puedan medir a partir de los elementos del producto software. El modelo también debe identificar, si es que existen, las relaciones entre las características de calidad del producto. De manera que podamos saber si mejorar una característica supone mejorar a su vez otra, o si por el contrario una mejora en una característica supone una pérdida en otra de dichas características.

Y probablemente la parte más complicada a la hora de definir el modelo de calidad, es disponer de unos umbrales contrastados y validados que reflejen el valor de calidad que se quiere alcanzar, es decir, por ejemplo cómo saber si cuando decimos que un producto tiene un 4% de código duplicado, eso es bueno o malo y cómo de bueno o malo es.

Como se ha comentado anteriormente, la nueva familia de

normas ISO/IEC 25000 contempla un modelo para la calidad del producto software que define las características y subcaracterísticas de calidad que se pueden medir. La dificultad es que esta familia de normas no determina un conjunto concreto de indicadores, métricas y umbrales que puedan ser tomados por las organizaciones como referente a la hora de evaluar y poder certificar la calidad de sus productos.

2) Proceso de Evaluación El objetivo del proceso de evaluación es definir las

actividades que se deben realizar para poder llevar a cabo la evaluación de la calidad del producto software. Es importante remarcar que el proceso de evaluación define el cómo evaluar, pero no el qué evaluar, que como veíamos antes estaba definido por el modelo.

El proceso de evaluación suele iniciarse por la selección de las partes del producto software que se van a evaluar: el código fuente, los requisitos, los modelos, los casos de pruebas, el producto en ejecución, etc. podrían ser algunos de los ejemplos de partes del producto software que se pueden evaluar. Además, durante el proceso se debe también identificar qué características se van a evaluar. Características de calidad que se han definido previamente en un modelo de calidad como hemos visto en el apartado anterior, de ahí la relación entre el proceso de evaluación y el modelo de calidad.

El proceso de evaluación debe definir el conjunto de pasos que el evaluador debe seguir, identificar las herramientas que se utilizarán, así como identificar qué personas participarán en la evaluación y cuáles serán las actividades en las que participarán.

El objetivo último del proceso de evaluación es generar un informe con los resulta-dos obtenidos, asegurando que dicho informe sea completo, repetible y legible para el público objetivo del mismo.

La ISO/IEC 25040:2011 también define un proceso de evaluación muy completo, cuyas actividades se han enumerado en la introducción del presente artículo. Aquí la dificultad es


130

que este proceso no está preparado para la certificación del producto software, sino solo para la parte de evaluación. Por tanto es necesario complementarlo con otro conjunto de pasos.

3) Entorno tecnológico de soporte El objetivo del entorno tecnológico es precisamente el de

asistir al proceso de evaluación y a la recolección de las métricas y umbrales definidos en el modelo de calidad.

Las herramientas que forman este tipo de entornos sirven para facilitar la obtención de los datos, ya sea parseando automáticamente el producto software o permitiendo al evaluador introducir los datos de una manera amigable. Estas herramientas deben poder también automatizar los algoritmos de medición, de manera que a partir de las métricas base que se hayan tomado, se puedan ir escalando dichos valores para obtener los indicadores de calidad. Además, estas herramientas también deben permitir presentar los resultados de una manera entendible dependiendo el público objetivo de los mismos.

Dentro de este tipo de herramientas hay que diferenciar aquellas que realizan medición de la calidad del producto software, obteniendo métricas de bajo nivel e indicadores. De aquellas herramientas que evalúan la calidad del producto software, escalando las métricas anteriores para dar una valoración de las subcaracterísticas y características de calidad del modelo. De aquí la relación también entre el modelo y el entorno tecnológico.

Aunque hoy en día existen ya en el mercado muchas herramientas de este tipo [25], todavía no existe ninguna que esté alineada a un modelo de calidad que siga la familia ISO/IEC 25000, de ahí la dificultad para poder elegir una que se adapte a las necesidades de una organización que quiera certificar la calidad de sus productos.

Una vez detallados los requisitos necesarios para la evaluación y certificación del producto y vistas las dificultades de las propuestas existentes, en el siguiente apartado se presenta el ecosistema creado y las soluciones adoptadas.

C. Ecosistema para la evaluación y certificación del producto software La certificación, entendida como la evaluación por una

entidad independiente y acreditada para llevar a cabo auditorías de producto software, es un ámbito que hasta ahora no está contemplado por la familia de normas ISO/IEC 25000 y que sin embargo, es de gran interés para los desarrolladores y/o adquisidores de producto software, ya que les permitiría identificar rápidamente la calidad de un producto software de una manera estandarizada.

Por esta razón, AENOR (Asociación Española de Normalización y Certificación) y el laboratorio de evaluación de la calidad del producto software AQC Lab, han elaborado una certificación basada en la familia de normas ISO/IEC 25000. Dadas las dificultades vistas en el apartado anterior para evaluar la calidad del producto en base a la ISO/IEC 25000, junto con la novedad de esta nueva certificación y por tanto el desconocimiento del sector sobre las necesidades para su implantación, se ha empezado a construir lo que se ha denominado como Ecosistema para la Evaluación y Certificación de la Calidad del Producto Software, con el objetivo de resolver las dificultades expuestas e identificar todas las entidades que deben participar en el proceso que permita obtener un certificado para el producto software.

El ecosistema está formado inicialmente por las siguientes entidades (Fig. 3):

Organizaciones que quieren certificar la calidad del producto. Estas organizaciones pueden ser tanto

empresas desarrolladoras de software (de cualquier dominio), como entidades que han externalizado sus desarrollos o directamente adquieren un producto software, independientemente del propósito del mismo. Esta entidad es el elemento central del ecosistema y su interés por la calidad del producto es el que motiva precisamente la evaluación y certificación del mismo.

Fig. 3. Modelo de calidad del producto software según la ISO/IEC 25010

Organismo certificador acreditado. En este caso dicho organismo es AENOR, quién tiene la experiencia de más de 20 años realizando auditorías de calidad de productos en otros sectores y que desde 2006 viene desarrollando el modelo para gobierno de las TIC basado en normas ISO [21], en el que recientemente ha incluido la propia norma ISO/IEC 25000 para llevar a cabo este tipo de auditorías de calidad del producto software. Para ello, AENOR ha desarrollado un reglamento interno de certificación del producto, de manera que a partir de un informe de evaluación emitido por un laboratorio acreditado y de una auditoría en las instalaciones de la empresa desarrolladora del producto, está en disposición de emitir un certificado sobre el nivel de calidad del mismo. Gracias a esta entidad del ecosistema, se complementa el proceso de evaluación, solucionando la dificultad que se identificaba anteriormente por la falta de un proceso de certificación.

Laboratorio acreditado para la evaluación de la calidad del producto. En este caso dicha entidad del ecosistema es AQC Lab. Una de las necesidades que se identificaron inicialmente para poder evaluar la calidad del producto software, fue disponer de una entidad externa capaz de emitir una evaluación independiente sobre el producto software. Con esta idea, en 2009 comienza la construcción de AQC Lab, un laboratorio que basado en la familia ISO/IEC 25000 permita, tanto a empresas desarrolladoras de software como a entidades que externalizan o adquieren software, disponer de un informe independiente que refleje la calidad del producto software. Con el objetivo de obtener un reconocimiento a la validez de las evaluaciones realizadas por AQC Lab, se decidió elaborar toda la infraestructura de gestión necesaria para conseguir la acreditación, siguiendo además para ello prácticas del desarrollo ágil como se expone en [26]. El resultado fue que en 2012 AQC Lab conseguía la acreditación de ENAC (Entidad Nacional de Acreditación) en la norma ISO/IEC 17025 [27], como el primer laboratorio para la evaluación de la calidad de aplicaciones software bajo la familia de normas ISO/IEC 25000. La acreditación de acuerdo a la norma ISO/IEC 17025 confirma la competencia técnica del laboratorio y


131

garantiza la fiabilidad en los resultados de los ensayos realizados. AQC Lab cuenta con los tres requisitos principales identificados anteriormente y que se han detallado previamente en [28]:

o Un Proceso de Evaluación, que adopta directamente la norma ISO/IEC 25040:2011, y la completa con los roles concretos del laboratorio y los procedimientos de trabajo desarrollados.

o Un Modelo de Calidad, que define las características, métricas y umbrales para evaluar el producto software, complementando así la norma ISO/IEC 25010:2011.

o Un Entorno tecnológico propio, formado por varios niveles de herramientas que permiten automatizar en gran medida las tareas de medición y evaluación del producto.

Gracias a esta entidad del ecosistema, se ha solucionado la dificultad de contar con un modelo de calidad del producto detallado hasta las métricas y umbrales, así como de disponer de un laboratorio acreditado para la emisión de informes de evaluación sobre el producto software, que son la entrada al proceso de certificación.

Consultores expertos en calidad de software. Antes de que las empresas puedan presentarse a una evaluación y certificación oficial, es necesario que cuenten con el apoyo y soporte a la mejora de sus productos ofrecido por consultores (internos o externos) que les permita controlar la calidad del producto a lo largo de todo el ciclo de vida y afrontar la certificación con garantías. Gracias a esta entidad del ecosistema, se soluciona la dificultad de contar con personal con experiencia para poder asegurar la calidad del producto software.

Empresas desarrolladoras de herramientas para la medición del producto software. A su vez, tanto el laboratorio de evaluación como los consultores expertos en calidad, necesitan de soporte al proceso mediante herramientas de medición. Por ello, son necesarias empresas que desarrollen este tipo de herramientas y que alineen las mismas a las mediciones y umbrales que después serán objeto de evaluación y certificación. Entre este tipo de herramientas se puede destacar Kiuwan1, que ya ha comenzado a alinear sus mediciones al modelo de calidad del laboratorio AQC Lab, u otras de software libre como SonarQube2. Gracias a este tipo de entidades en el ecosistema, se solucionan las necesidades de contar con entornos tecnológicos que den soporte a la medición y la evaluación del producto.

De esta manera, por medio de estas herramientas, estos expertos en calidad software, del laboratorio AQC Lab y de AENOR, las empresas pueden evaluar, mejorar y certificar la calidad de sus productos software aplicando la familia ISO/IEC 25000, conformándose así el primer ecosistema completo para llevar a cabo este proceso.

IV. PILOTO DE EVALUACIÓN Y CERTIFICACIÓN DE LA CALIDAD DEL PRODUCTO SOFTWARE

Una vez alcanzada la acreditación del laboratorio, se estableció un proceso de trabajo con AENOR que permitiera que los productos software, una vez se hubieran evaluado y obtenido un nivel adecuado de calidad, pudieran también conseguir un certificado.

1 www.kiuwan.com 2 http://www.sonarqube.org/

Como resultado se creó un procedimiento que, a partir del informe del laboratorio acreditado y tras una auditoría por parte de AENOR, permitía certificar la calidad del producto software bajo estudio realizando los siguientes pasos (Fig. 4):

Fig. 4. Ciclo de Evaluación y Certificación del Producto Software

Paso 1: El proceso comienza cuando la organización interesada en la calidad del producto software solicita una evaluación al laboratorio acreditado AQC Lab. Para ello debe rellenar un formulario con las características del producto software que se quiere evaluar, que es analizado por el laboratorio para emitir un contrato de evaluación con las condiciones del servicio. Aceptado este contrato, la organización hace entrega al laboratorio del producto software a evaluar. A partir de aquí, AQC Lab haciendo uso del entorno basado en ISO/IEC 25000 y acreditado por ENAC (modelo, proceso y herramientas) detallado en [28], realiza la evaluación. Este proceso suele tener una duración estimada de 2-3 semanas, dependiendo de las características del producto bajo evaluación.

Paso 2: El resultado del paso anterior es un informe de evaluación con los resultados obtenidos, que es entregado a la organización solicitante. En este paso, puede ocurrir que el nivel de calidad obtenido por el producto software no sea suficientemente bueno, en cuyo caso la organización solicitante, apoyada por los consultores expertos del ecosistema, deberán refactorizar el producto para mejorar el nivel de calidad. En este caso, el tiempo que puede transcurrir dependerá el número de defectos que se deben solucionar y de la cantidad de recursos que la organización pueda dedicar para tal fin. Una vez refactorizado el producto, la organización deberá repetir el paso 1 del proceso para volver a obtener un informe de evaluación favorable.

Paso 3: Cuando el producto software ha obtenido en la evaluación un nivel de calidad favorable, la organización podrá contactar con AENOR solicitando la certificación del producto e indicando la referencia previa de la evaluación que ha pasado realizada por un laboratorio acreditado.

Pasos 4 y 5: AENOR contacta con AQC Lab (Paso 4) para comprobar que la empresa realmente ha evaluado su producto de software y el nivel obtenido es adecuado para la certificación. En este caso, el Laboratorio facilita a AENOR el informe de evaluación (paso 5), quien lo contrasta con la información facilitada por la empresa.

Paso 6: Finalmente AENOR, analizará el informe de evaluación facilitado por el laboratorio y realizará una visita a la organización solicitante para, siguiendo con su reglamento interno de auditoría definido para el producto software, revisar el producto y las características del


132

mismo. Como resultado de este proceso de auditoría de certificación, AENOR emitirá un informe y entregará a la organización un certificado que acredite la calidad del producto software evaluado. Este informe identifica entre otros a la organización solicitante, el producto certificado y su versión concreta, las características de calidad del modelo evaluadas y el informe del laboratorio acreditado que recoge los resultados de evaluación sobre los que se soporta el certificado emitido. Todo lo anterior permitió realizar a lo largo de 2013 un proyecto piloto de evaluación y certificación de los primeros productos software [22]. El listado actualizado de productos certificados se puede encontrar en la Web de iso250003. A continuación, en los siguientes apartados se presenta el proceso concreto seguido por una de las empresas que participó en dicho proyecto piloto, detallando la experiencia vivida y las mejoras realizadas a su producto software.

A. Presentación de la empresa y del producto evaluado Enxenio S.L. se dedica al diseño, desarrollo y operación de

sistemas de información para todo tipo de organizaciones. Creada en 2004, cuenta con una plantilla de unas 20 personas, la mayoría de ellas dedicadas a actividades de análisis, diseño y desarrollo de sistemas de información. Enxenio ha desarrollado varios productos software propios, y también ofrece a sus clientes servicios de desarrollo a medida. Sus principales áreas de trabajo son los sistemas de información geográfica (GIS), aplicaciones para la gestión de contenidos digitales para los sectores educativo y editorial, comercio electrónico y sistemas de gestión y soporte de procesos de negocio.

Los esfuerzos de gestión y mejora de la calidad que Enxenio ha llevado a cabo hasta este proyecto piloto se han centrado en la calidad de sus procesos de gestión de proyectos, desarrollo de software y seguridad de la información. Desde 2009 Enxenio cuenta con un sistema de gestión de seguridad de la información certificado bajo ISO 27001, y un sistema de gestión de proyectos y desarrollo de software certificado en ISO 12207/ISO 15504 - nivel 2. Así, el proyecto piloto que se describe en esta sección supuso un cambio hacia la evaluación y certificación no solo de los procesos de la organización, sino también de los productos desarrollados.

El producto evaluado en el proyecto piloto de evaluación y certificación es xCloud Bookstore4, una plataforma para la distribución y venta online de contenidos digitales. Este producto está orientado a organizaciones en los sectores educativo, editorial y cultural. Esta plataforma permite a cualquier organización ofrecer, vender y distribuir contenidos digitales a través de un canal propio, sin depender de intermediarios (y de los costes que esa dependencia implica). Uno de los objetivos en el diseño y desarrollo de este producto fue identificar y dar soporte a los requisitos que cualquier cliente potencial pudiera necesitar. Sin embargo, es posible que en muchos casos sean necesarias ciertas adaptaciones del producto a las necesidades particulares de un cliente, por lo que la mantenibilidad del producto cobra una gran importancia de cara a su comercialización.

Las expectativas de Enxenio de cara al proyecto de evaluación y certificación eran asegurar que el producto presentara un nivel de mantenibilidad alto (por la importancia que la mantenibilidad tiene de cara a la evolución y adaptación

3 www.iso25000.com/ 4 http://www.xcloud-bookstore.com

del producto a los nuevos clientes), y que este nivel de mantenibilidad estuviera certificado por un organismo independiente y ampliamente reconocido.

B. Proceso de evaluación y certificación de la mantenibilidad La evaluación y certificación del producto se llevó a cabo

en tres fases. El laboratorio AQC Lab realizó una primera evaluación del producto en base al modelo de calidad presentado en secciones anteriores. Esta primera evaluación del producto dio lugar a un informe detallado con el nivel de calidad alcanzado en cada una de las características que forman el modelo, y con un informe exhaustivo de aquellos componentes del código fuente del producto que incumplen alguna de las reglas y métricas de mantenibilidad

El nivel global de mantenibilidad alcanzado por el producto inicialmente fue un nivel 2, lo que está por debajo del umbral mínimo para poder optar al certificado de AENOR (nivel 3 o superior).

Esta primera evaluación permitió a Enxenio conocer con mucho detalle (nivel de línea de código) aquellos aspectos del producto que podrían suponer un problema para su mantenibilidad en el futuro, como eran:

Baja Analizabilidad: lo que penalizaba al equipo de desarrollo a la hora de poder detecta qué partes del producto implementaban una funcionalidad concreta.

Baja Modularidad: lo que suponía un riesgo a la hora de corregir un módulo sin que otros independientes se vieran afectados.

Baja Capacidad para ser modificado: lo que afectaba a la facilidad para introducir cambios en el producto sin introducir nuevos errores.

Baja Capacidad para ser reutilizado: lo que representaba un riesgo de que los módulos del producto no se pudieran reutilizar por su acoplamiento con otras partes.

Baja Capacidad para ser probado: lo que impedía confiar en que las pruebas realizadas al sistema fueran lo suficientemente completas.

En base al informe proporcionado por AQC se llevó a cabo un proyecto de mejora con el fin de corregir aquellos aspectos señalados en el informe de evaluación.

Tras la refactorización y mejora del producto por parte de Enxenio, AQC llevó a cabo una nueva evaluación del producto, en la que el nivel de mantenibilidad alcanzado fue 4. De nuevo, se emitió un informe con los resultados de la evaluación, detallando el nivel alcanzado para cada una de las características que contempla el modelo de mantenibilidad. Los resultados de ambas evaluaciones se muestran en la Fig. 5.



133

Como se puede ver en la figura, el nivel de mantenibilidad se mejoró en todas las sub-características de calidad, especialmente en los casos de capacidad de ser reutilizado y capacidad de ser modificado. El resultado de las dos evaluaciones y las acciones de refactorización suponen una mejora efectiva del nivel de mantenibilidad del producto, lo que redundará en menores costes de mantenimiento en un futuro. El proyecto de mejora de la mantenibilidad del producto supuso para Enxenio un esfuerzo de 80 horas, mientras que las dos evaluaciones realizadas supusieron un esfuerzo total de 70 horas para los técnicos del laboratorio AQC Lab.

Tras los resultados de la segunda evaluación, Enxenio solicitó la certificación del nivel de mantenibilidad del producto a AENOR. Tras analizar el informe emitido por AQC Lab, AENOR llevó a cabo una auditoría in-situ de la empresa durante una jornada de trabajo. En dicha auditoría se comprobó que la empresa cuenta con los recursos e infraestructura necesarios para garantizar la mantenibilidad del producto en el futuro, obteniendo como resultado el certificado de calidad de producto emitido por AENOR.

Los principales resultados obtenidos por parte de Enxenio son:

Alto nivel de mantenibilidad del producto: la primera consecuencia obtenida por Enxenio en el proyecto piloto es que la mantenibilidad del producto se ha mejorado de forma efectiva. Esta mejora redundará en menores costes de mantenimiento, evolución y adaptación del producto a las necesidades de los nuevos clientes. Desde este punto de vista, el esfuerzo de refactorización del producto se ve como una inversión que supondrá un ahorro de costes en el futuro.

Modelo de referencia independiente y accesible: aunque desde hace tiempo existen distintas herramientas de análisis del código fuente y extracción de métricas, el modelo desarrollado por AQC y AENOR proporciona un marco de referencia independiente contra el que medir las características de cualquier producto software.

Certificado de calidad emitido por entidades acreditadas y reconocidas: para Enxenio, el hecho de que el producto cuente con un certificado de calidad respaldado por entidades como AENOR y AQC supone un sello de garantía de gran importancia para los potenciales clientes. En la Fig. 6 se muestra el certificado conseguido por Enxenio con su producto software.

Aplicación en futuros proyectos como garantía para el cliente: contar con un sello de calidad de producto (y no solo de proceso) emitido por una entidad independiente es una de las mejores garantías de calidad que se pueden ofrecer a un cliente, ya sea en la adaptación de un producto estándar o en el desarrollo de un producto a medida.

Así, para Enxenio la evaluación y certificación de calidad de producto conforme a ISO 25000 supone una forma de ofrecer a sus futuros clientes una garantía de calidad aún mayor.

Incorporación de evaluación de producto a los procesos de la empresa: tras esta experiencia, Enxenio ha incorporado a sus procesos de gestión y desarrollo aspectos de evaluación de la calidad de los productos. Así, la gestión de la calidad no se centra solo en los procesos, sino que llega a los productos generados.

V. CONCLUSIONES Y TRABAJO FUTURO La calidad del producto software es una de las principales

preocupaciones tanto para las empresas desarrolladoras, como para los organismos que lo adquieren. El presente artículo ha presentado una solución, formada por un ecosistema completo, que permiten realizar la evaluación del producto software y alcanzar posteriormente una certificación de calidad. Además, para mostrar la aplicación práctica de la evaluación y certificación de la calidad del producto software, se han presentado también los detalles de un proyecto piloto de evaluación y certificación realizado, con los datos concretos obtenidos por una de las empresas participantes en dicho proyecto.


Entre los beneficios obtenidos, las empresas participantes destacaron haber reducido hasta en un 75% las incidencias correctivas, hasta en un 40% el tamaño de sus productos y hasta en un 30% los tiempos en las tareas de mantenimiento. Y tras este piloto, son varios los productos que a nivel nacional e internacional ya se han evaluado siguiendo este nuevo esquema, estando algunos de ellos ya en fase de certificación.

Por otro lado, indicar que AENOR y AQC Lab siguen trabajando para ampliar el alcance de las evaluaciones y certificaciones del producto software, de manera que se puedan abordar poco a poco todas las características de calidad identificadas por la familia ISO/IEC 25000.

AGRADECIMIENTOS Esta investigación forma parte de los proyectos: GEODAS-

BC (Ministerio de Economía y Competitividad, TIN2012-37493-C03-01), SDGear (Ministerio de Industria, Energía y Turismo, TSI-100104-2014-4) e IMPACTUM (Consejería de Educación, Ciencia y Cultura de la JCCM, PEII-2014-017-A), todos ellos dentro del Fondo Europeo de Desarrollo Regional FEDER.

REFERENCIAS [1] M.G. Piattini and J. Garzás, Fábricas de software: experiencias,

tecnologías y organización (2ª edición actualizada). 2010, Paracuellos del Jarama (Madrid): RA-MA.


134

[2] Standish-Group, The CHAOS Manifesto: Think Big, Act Small. 2013, The Standish Group.

[3] B.W. Boehm, et al., Characteristics of Software Quality. 1978: North-Holland.

[4] ISO, ISO/IEC 9126, Software Product Evaluation–Quality Characteristics and Guidelines for their Use. 2001, International Organization for Standardization.

[5] ISO, ISO/IEC 14598-5:1998 - Information technology -- Software product evaluation -- Part 5: Process for evaluators. 1998, International Organization for Standardization: Ginebra.

[6] I. Heitlager, T. Kuipers and J. Visser, A Practical Model for Measuring Maintainability, in Quality of Information and Communications Technology, 2007. QUATIC 2007. 2007. p. 30-39.

[7] ISO, ISO/IEC 25000, Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE. 2014: Ginebra, Suiza.

[8] M. Rodríguez and M. Piattini, Systematic review of software product certification, in CISTI 2012: 7th Iberian Conference on Information Systems and Technologies. 2012: Madrid. p. 631-636.

[9] B. Kitchenham, Guideline for performing Systematic Literature Reviews in Software Engineering. Version 2.3. 2007, University of Keele (Software Engineering Group, School of Computer Science and Mathematics) and Durham (Department of Computer Science).

[10] J. Biolchini, P. Gomes, A. Cruz and G. Travassos, Systematic Review in Software Engineering. 2005, Systems Engineering and Computer Science Department, UFRJ: Rio de Janeiro, Brazil.

[11] P. Heck, M. Klabbers and M. van Eekelen, A software product certification model. Software Quality Journal, 2009. 18(1): p. 37-55.

[12] F. Carvalho, S.R.L. Meira, B. Freitas and J. Eulino, Embedded software component quality and certification. Conference Proceedings of the EUROMICRO, 2009: p. 420-427.

[13] E. Burger and R. Reussner, Performance certification of software components. Electronic Notes in Theoretical Computer Science, 2011. 279(2): p. 33-41.

[14] A. Serebrenik, A. Mishra, T. Delissen and M. Klabbers, Requirements certification for offshoring using LSPCM. Proceedings - 7th International Conference on the Quality of Information and Communications Technology, QUATIC 2010, 2010: p. 177-182.

[15] J.H. Yahaya, A. Deraman and A.R. Hamdan, SCfM_PROD: A software product certification model. 2008 3rd International Conference on Information and Communication Technologies: From Theory to Applications, ICTTA, 2008.

[16] J. Yahaya, A. Deraman and A.R. Hamdan, Continuously ensuring quality through software product certification: A case study. 2010 International Conference on Information Society, i-Society 2010, 2010: p. 183-188.

[17] J. Hatcliff, et al., A Software Certification Consortium and its Top 9 Hurdles. Electronic Notes in Theoretical Computer Science, 2009. 238(4): p. 11-17.

[18] J. Morris, G. Lee, K. Parker, G.A. Bundell and C.P. Lam, Software component certification. Computer, 2001. 34(9): p. 30-36.

[19] R. Baggen, J.P. Correia, K. Schill and J. Visser, Standardized code quality benchmarking for improving software maintainability. Software Quality Journal, 2012. 20(2): p. 287-307

[20] A. Alvaro, E.S. De Almeida and S.L. Meira, Towards a software component certification framework. Proceedings - International Conference on Quality Software, 2007: p. 298-303.

[21] C.M. Fernández and M. Piattini, Modelo para el Gobierno de las TIC basado en normas ISO. 2ª ed. 2015, Madrid: AENOR.

[22] M. Rodríguez, C.M. Fernández and M. Piattini, ISO/IEC 25000 Calidad del Producto Software. AENOR. Revista de la Normalización y la Certificación, 2013(288): p. 30-35.

[23] ISO, ISO/IEC 25010, Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models. 2011: Ginebra, Suiza.

[24] ISO, ISO/IEC 25040 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation process. 2011: Ginebra, Suiza.

[25] P. Tomas, M.J. Escalona and M. Mejias, Open source tools for measuring the Internal Quality of Java software products. A survey. Computer Standards & Interfaces, 2013(36): p. 244-255.

[26] J. Verdugo, M. Rodríguez and M. Piattinni, Using Agile Methods to Implement a Laboratory for Software Product Quality Evaluation, in 15th International Conference on Agile Software Development (XP 2014). 2014: Roma (Italia).

[27] ISO, ISO/IEC 17025:2005. General requirements for the competence of testing and calibration laboratories. 2005, International Organization for Standardization.

[28] M. Rodríguez and M. Piattini, Entorno para la Evaluación y Certificación de la Calidad del Producto Software, in XIX Jornadas de Ingeniería del Software y Bases de Datos JISBD’2014. 2014: Cadiz. p. 163-176.

Moisés Rodríguez Monje. Ingeniero Superior en Informática y Máster en Tecnologías Informáticas Avanzadas por la Universidad de Castilla-La Mancha. Auditor CISA por ISACA y auditor Jefe por AENOR en ISO/IEC 15504 – 12207. Socio-Director en Alarcos Quality Center y Director General del laboratorio AQC Lab para la evaluación de la calidad del producto software

bajo ISO/IEC 25000.

Óscar Pedreira Fernández. Doctor e Ingeniero en Informática por la Universidad de A Coruña. Profesor en la Universidad de A Coruña y Socio de la empresa Enxenio, spin-off del Laboratorio de Bases de datos. Responsable de los sistemas de gestión de calidad ISO 27001, ISO 15504 e ISO 25000.

Carlos Manuel Fernández. Ingeniero en Informática por la Universidad Politécnica de Madrid y Máster en Dirección de Empresas por el CECO-Madrid. Auditor CISA y CISM por ISACA. Actualmente es Profesor en Máster de TICs (entre otras universidades: UPM, UAH, UNIR, URJC, etc.). En la actualidad es Gerente de

Certificaciones TICs en AENOR, coordinando más de 500 empresas en España, LATAM y Europa.

Vásquez, A., Peláez, E., Ochoa, X. 2015. Predictor Basado en Prototipos Difusos y Clasificación No-supervisada. Revista Latinoamericana de Ingeniería de Software, 3(3): 135-140, ISSN 2314-2642

135

Predictor Basado en Prototipos Difusos y Clasificación No-supervisada

Aníbal Vásquez, Enrique Peláez, Xavier Ochoa Facultad de Ingeniería en Electricidad y Computación, Centro de Tecnologías de Información

Escuela Superior Politécnica del Litoral, ESPOL Guayaquil, Ecuador

{anibal.vasquez, epelaez, xavier}@cti.espol.edu.ec

Resumen— La construcción de prototipos difusos es un método

que permite describir a los elementos más representativos de un clúster, a través de su tipicidad. Los prototipos, como los datos más representativos de cada clúster, pueden ser usados en un proceso de clasificación como datos de entrenamiento. Estos prototipos y los clusters pueden ser construidos mediante algoritmos de clustering difuso; los clusters representados por los prototipos poseen variables descriptivas y atributos que pueden ser asociados a nuevos datos. El siguiente trabajo propone una arquitectura que utiliza herramientas de clustering y prototipado difuso, para clasificación no-supervisada y predicción a través de la extracción de variables descriptivas. El desarrollo de un caso de estudio permitió validar el modelo de clasificación para predecir el riesgo de falla en el rendimiento académico de estudiantes, basado en su carga semestral y rendimiento académico, en la selección de cursos antes de registrarse, con un porcentaje de certeza significativo.

Palabras Clave—Inteligencia Artificial, Prototipos Difusos, Lógica Difusa, Clasificación No-supervisada, Predicción.

I. INTRODUCCIÓN La deserción académica es un problema actual en el sistema

de educación superior, esto ocurre cuando un estudiante abandona su programa de estudios y en consecuencia no culmina su carrera de manera exitosa, este problema no solo afecta a los estudiantes sino también a las universidades en sí, pues al ofrecer educación incompleta a sus estudiantes, no se usan de forma eficiente los recursos como infraestructura y profesores que imparten las materias [1]. La predicción del rendimiento académico en estudiantes universitarios ha sido objeto de estudio en años recientes, pues es fundamental evaluar y monitorear el desempeño académico en el sistema educativo; muchas metodologías desarrolladas han hecho uso de técnicas de minería de datos e inteligencia computacional, para así dar un pronóstico a los estudiantes antes de tomar determinados cursos en el semestre, este pronóstico es soportado generalmente por datos académicos, socioeconómicos y otras variables demográficas; Bhardwaj y Pal [2] usaron un modelo basado en teoría de Bayes para predecir el rendimiento mediante clasificación; Pandey y Taruna [3] propusieron un modelo de clasificación basado en árboles de decisión para la predicción de rendimiento, además Oladokun et al. [4] y Naser et al. [5] propusieron el uso de redes neuronales para la predicción de rendimiento basada en clasificación supervisada; el uso de estas técnicas generalmente poseen un nivel de precisión mayor al 70%, esto permite ayudar a los estudiantes en el proceso de decisión al tomar materias en un nuevo periodo académico y así contribuir a mejorar su desempeño.

Este trabajo tiene como objetivo proponer un modelo para estimar el riesgo de reprobación de un estudiante en un periodo académico, dicho modelo es soportado por datos académicos históricos, los cuales son usados para establecer similitudes entre los estudiantes, a través de la extracción de las características que describen su desempeño académico y la carga académica que implican las materias que debe cursar, para así, mediante el uso de variables descriptivas, asociar un valor de riesgo de reprobación dependiendo de su similitud con otros y la carga académica que representa en el periodo en el que la tomará.

El modelo propuesto utiliza herramientas de clustering y prototipado difuso para la clasificación no-supervisada y la predicción mediante asociación de variables descriptivas.

El clustering es una técnica de minería de datos que permite realizar sub-agrupaciones denominadas clusters dentro de un conjunto, permitiendo clasificar los elementos de este conjunto en base a una similitud entre ellos; definido formalmente como [6]:

(1)

(2)

Donde es el cluster subconjunto de , tal que , y .

Existe una generalización de esta técnica para conjuntos difusos, esta generalización establece que cada cluster puede ser representado como un conjunto difuso [7], permitiendo definir una pertenencia parcial de los elementos a un cluster, e incluso pertenecer de forma simultánea a más de un cluster, así cada uno de estos elementos característicos, llamados prototipos, pueden describir a los demás elementos de una categoría.

Este trabajo se encuentra organizado de la siguiente manera: la sección 2 describe la creación de prototipos, y los algoritmos usados para clustering difuso y su validación; la sección 3 describe las variables extraídas en el contexto académico; la sección 4 describe la arquitectura planteada para la estimación de riesgo de reprobación, basada en prototipos difusos y clasificación no-supervisada, mediante técnicas de clustering; la sección 5 presenta los resultados obtenidos, se realiza un análisis de estos y se presenta un contraste con una técnica de minería de datos convencional, como la regresión logística, y finalmente en la sección 6 se describen las conclusiones.


136

II. CONSTRUCCIÓN DE PROTOTIPOS DIFUSOS MEDIANTE MÉTODOS DE CLUSTERING Y VALIDACIÓN DEL PROCESO La construcción de prototipos difusos se basa en una noción

de tipicidad, la cual es una medida que se asocia a un elemento perteneciente a un determinado cluster, además esta medida permite determinar qué tan bien puede caracterizar o no a los demás elementos del cluster, esta medida se obtiene mediante dos parámetros que describen: qué tan semejante es un elemento a los demás de su propia categoría; y, qué tan diferente o disímil es con respecto a los otros elementos que no pertenecen a su categoría; Rifqi [8] propone la agregación de estos parámetros de semejanza y disimilitud para estimar el grado de tipicidad de un elemento, definido formalmente como:

(3)

Donde:

(4)

(5)

en (4) describe la medida de semejanza de un elemento dentro de la categoría , y esta se define por las distancias entre y los demás elementos , que pertenecen a la misma

categoría . en (5) describe la medida de disimilitud de un elemento

dentro de la categoría , esta se define por las distancias entre y los otros elementos que no pertenecen a su misma categoría .

Las distancias y son definidas a través de funciones decrecientes [9], estas son transformaciones lineales que parten de productos escalares o medidas de disimilitud [10], las cuales utilizan distancias normalizadas euclidianas o no-euclidianas para describir la semejanza entre dos elementos; entre las transformaciones lineales usadas, generalmente para describir funciones decrecientes, se encuentran: la transformada de Laplace, la transformada generalizada de Gauss, y funciones sigmoides. Siendo una distancia que describe semejanza, definida por una función decreciente en el rango de , por lo tanto es posible definir la distancia , que describe disimilitud, mediante el complemento a uno; esto es [11]:

(6)

es también una función que se encuentra dentro del rango .

Una vez determinadas las medidas de tipicidad de cada elemento, el prototipo difuso para la categoría puede ser construido mediante una operación de agregación sobre los elementos que cumplen con una tipicidad mayor a una condición de umbral definida, así el prototipo difuso lo podemos expresar formalmente como [12]:

(7)

Donde es el umbral para las medidas de tipicidad en los elementos que construirán el prototipo para la categoría .

Existen varios algoritmos de clustering difuso que permiten construir prototipos; Fuzzy C-Means (FCM), basado en un

proceso de media iterativa donde los grados de membresía asociados a cada elemento describen el grado de pertenencia de un elemento a un cluster, los valores de membresía de cada elemento a cada cluster son definidos por la matriz de membresía , donde cada elemento es definido formalmente como [13]:

(8)

Donde es un elemento del cluster ; es la distancia entre y el prototipo del cluster y definido por la norma

tal que, ; de igual manera está definido por la norma , pero esta describe la distancia entre y el prototipo de cada cluster tal que, ; es el exponente de ponderación, el cual determina cuan difusos son los límites de cada cluster, por la forma de la curvatura de la función exponencial en ; el exponente de ponderación y el número de clusters son parámetros definidos por el usuario. FCM puede ser considerado como una optimización de la semejanza ya que mediante el complemento de los valores de membresía se puede determinar la disimilitud asociada a cada elemento.

En los procesos de custering difuso existen medidas de validación que permiten estimar el número de clusters que describen un conjunto de datos en varias categorías, de esta forma podemos definir un proceso de categorización no-supervisada [14], estas medidas surgen como una necesidad de la validación de clusters en conjuntos multidimensionales. Una de estas medidas es el coeficiente de validación de Dave [15], a partir del coeficiente de partición de Bezdeck [13], definido formalmente como:

(9)

Donde es el número de clusters a validar y es el coeficiente de partición de Bezdeck, este último definido como:

(10)

El objetivo del coeficiente de Dave es la optimización mediante minimización para el número de clusters , tal como [14]:

(11)

El número de clusters obtenido en el proceso de validación, permite definir las categorías en el proceso de clustering, para así construir los prototipos difusos que pueden ser usados como datos de entrenamiento por una Máquina de Soporte de Vectores (SVM) [16] o técnicas de defusificación [17], mediante las cuales podemos clasificar nuevos datos y predecir su comportamiento mediante variables descriptivas asociadas a cada categoría.

III. EXTRACCIÓN DE VARIABLES EN EL CONTEXTO ACADÉMICO Las medidas usadas en el proceso de clustering son

extraídas de la historia académica de estudiantes, estas variables extraídas son consideradas como características que permiten la abstracción de la carga académica semestral y el rendimiento de un estudiante.


137

La carga académica semestral es descrita mediante medidas asociadas a cada materia que definen qué tan difícil es aprobarlas, y con qué rigurosidad son calificadas; Caulkins et. al [18] introdujeron las medidas de dificultad y rigurosidad, estas medidas están definidas a su vez por: el promedio académico de los estudiantes y la calificación que obtuvo cada uno de ellos en un curso.

La medida de dificultad es definida formalmente como:

(12)

Y la rigurosidad es:

(13)

Donde es el promedio académico de un estudiante , es la calificación del estudiante en la materia , y es el

número de estudiantes que han cursado la materia . Además, Mendez et. al [19] introdujeron la medida de

distribución de calificaciones, la cual es una medida asociada igualmente a una materia, y describe la asimetría de la distribución estadística de la diferencia entre el promedio académico de cada estudiante, que ha cursado la materia a medir, y la calificación obtenida por cada estudiante en dicha materia, esta es definida formalmente como:

(14)

Estas medidas son usadas como vector de características, este vector formado por las tres medidas antes descritas define la carga académica semestral, basada en la dificultad y rigurosidad con que es calificada una materia.

A través de esta medida es posible describir el rendimiento de un estudiante mediante su historia académica, y extraer las variables que describan las habilidades que adquieren al aprobar cada materia, independientemente del nivel en el que el estudiante se encuentre, Mendez et. al [19] propuso el uso de un Análisis Exploratorio de Factores [20] para develar dichas estructuras en la malla curricular de la carrera de Ingeniería en Ciencias Computacionales de la Universidad ESPOL, este análisis develó 5 factores que componen el núcleo de 26 materias en la malla curricular, estos factores son:

1. Factor de preparación en ingeniería básica 2. Factor de temas avanzados de Ciencias

Computacionales 3. Factor de interacción con el cliente 4. Factor de programación 5. Factor de cursos no estrechamente relacionados con

las Ciencias Computacionales El Factor de preparación en ingeniería básica está

conformado por materias que están relacionadas con las bases generales para las carreras de ingeniería como: cálculo, física, estadísticas y química, estas materias permiten el desarrollo de la habilidad para entender conceptos abstractos e interpretar fenómenos; el Factor de temas avanzados de Ciencias Computacionales agrupa materias relacionadas a tópicos actuales de las Ciencias Computacionales como: Inteligencia Artificial, Sistemas Operativos, Interacción Humano-computador, Ingeniería de Software, etc., estas materias permiten el desarrollo de la habilidad para identificar los componentes de un sistema y su relación; el Factor de interacción con el cliente está conformado por materias que

permiten expresarse de forma apropiada, verbal y escrita, estas permiten desarrollar la habilidad para comunicarse con usuarios finales y clientes, parte del proceso de desarrollo de software; El Factor de programación agrupa materias como Lenguajes de Programación y Fundamentos de Programación, las cuales permiten desarrollar la habilidad para programar, necesaria en el proceso de desarrollo de software para manejar conceptos, estrategias y patrones de diseño; finalmente el Factor de cursos no estrechamente relacionados con las Ciencias Computacionales está formado por materias generalmente relacionadas a la ingeniería eléctrica.

Con base en estas agrupaciones de materias interrelacionadas que definen los factores en la malla curricular, se propone una medida que describe el desempeño en un estudiante para las materias dentro de dichas agrupaciones, la medida propuesta se puede definir como:

(15)

Donde es el grupo de materias del factor ; es el número de materias en el factor que ha aprobado

un estudiante , es el número de materias en el factor que ha tomado un estudiante , y es la calificación del estudiante en la materia dentro de . Esta medida está formada por dos componentes en una multiplicación, el primer componente describe la eficiencia del estudiante para aprobar las materias en , y el segundo es una analogía al promedio académico, pero solo para las materias en el factor .

De esta forma el rendimiento de un estudiante puede ser definido por un vector de características compuesto por las medidas dentro de cada uno de los cinco factores.

Estos vectores asociados a carga académica semestral y rendimiento académico pueden ser usados en un proceso de clustering, permitiendo clasificar de forma no-supervisada a estudiantes en combinación con semestres, y así predecir su riesgo de reprobación basado en la tasa de reprobación de estudiantes con características similares.

IV. DISEÑO DEL PREDICTOR DE RIESGO DE REPROBACIÓN El prototipo diseñado está conformado por tres

componentes principales: un componente de pre-procesamiento, un componente de clustering y un componente para clasificar y estimar el riesgo de reprobación, en la figura 1 se puede apreciar el diagrama de componentes del software de estimación de riesgo de reprobación.

Fig. 1. Diagrama de componentes del software de estimación de riesgo de

reprobación


138

El componente de pre-procesamiento tiene la función de seleccionar los atributos y extraer las características en la historia académica de los estudiantes; características que son usadas por el componente de clustering, el cual construye los prototipos y determina los clusters, mediante un proceso de validación, para generar las categorías de estudiantes y semestres; las categorías obtenidas son usadas luego, en el componente de estimación y clasificación, para estimar la razón de reprobación asociada a cada grupo de estudiante-semestre, el cual también clasifica nuevos datos de estudiantes mediante defusificación y asociarlos, según su valor de membresía, dada por la similitud a una categoría, a un riesgo de reprobación; y así predecir la reprobación en al menos una materia durante el semestre.

V. RESULTADOS Varios experimentos fueron realizados para el análisis de la

precisión del modelo propuesto, para lo cual se realizaron pruebas usando los datos académicos históricos de estudiantes de Ingeniería en Ciencias Computacionales registrados entre los años 1978 y 2013, todas las calificaciones fueron convalidadas y representadas con el núcleo de la malla curricular de la carrera, el cual está compuesto por 26 materias como se menciona en [19].

Se realizó una validación del número de clusters obtenidos en el proceso de clustering mediante la optimización del índice de Dave, para este proceso se usaron las cinco medidas que describen rendimiento con el objetivo de categorizar los estudiantes; en esta prueba se obtuvo un número de clusters

con índice de siendo el máximo valor, en la figura 2 se puede observar el gráfico de radar para las medidas en cada uno de los clusters obtenidos.

Fig. 2. Gráficos de radar en cada cluster de estudiantes, las cinco medidas de

habilidades

Como se puede observar en el gráfico, el primer cluster está formado por estudiantes que poseen habilidades en los cinco factores relativamente equilibradas a excepción del factor 5, ligado a los cursos no estrechamente relacionados a Ciencias Computacionales; el segundo cluster está formado por estudiantes con medidas mayormente bajas en todos los factores a excepción del factor 3, el cual está relacionado a materias con un fuerte componente de interacción con el cliente; el tercer cluster está conformado por estudiantes con una medida relativamente baja en el factor 4, factor relacionado a las habilidades de programación, y en los demás factores posee una medida relativamente alta; en el cuarto cluster

podemos encontrar estudiantes con medidas relativamente altas y equilibradas; finalmente en el quinto cluster encontramos estudiantes con medidas generalmente bajas. En este experimento se pudo identificar los clusters que serán usados en el contexto de categorías de estudiantes.

Para el análisis del nivel de certeza que posee el modelo, se realizó una verificación con el Score de Brier [21], el cual permite medir la precisión en un modelo de predicción, esto se realiza con el contraste entre la probabilidad predicha y la frecuencia relativa observada, para este caso la verificación fue realizada en el pronóstico del riesgo de reprobación. El Score de Brier puede ser descompuesto en tres términos que describen [22]: la incertidumbre de que ocurra o no el evento; la confiabilidad dada por la cercanía entre la probabilidad pronosticada y la probabilidad real; y la resolución que define la diferencia entre la probabilidad de los pronósticos y el promedio observado; con estos términos es posible determinar el score de skill de Brier el cual mide la diferencia entre el score de la predicción y el score de un modelo no cualificado; para valores negativos del score de skill se puede interpretar al modelo como no cualificado para predicción.

Para el análisis con el primer término del año 2013 se encontró un score de Brier , cercano a cero, un score de skill positivo ; con una

cercana a cero, una igualmente cercana a cero y además

un porcentaje de incertidumbre de 24.88%, el riesgo pronosticado vs. la frecuencia relativa observada se puede observar en el gráfico de confiabilidad en la figura 3.

Fig. 3. Confiabilidad para la estimación de riesgo de falla en estudiantes de

Ciencias Computacionales que tomaron materias en el término académico 2013-I usando el modelo propuesto.

En el análisis con el segundo término del 2013 se encontró un score de Brier de , aproximado al score del primer semestre, un score de skill también positivo, con una muy cercana a cero, una también cercana a cero, y una incertidumbre de 24.99%, en la Fig. 4 se puede observar el gráfico de confiabilidad para este caso.

Se realizó un contraste entre el modelo y una técnica comúnmente usada en minería de datos, Regresión Logística [23], para predecir el riesgo de reprobación utilizando el mismo conjunto de datos. Como resultado de esta verificación se obtuvo un score de Brier , para el primer semestre del 2013 y un score de skill , con una

; además, una , con una incertidumbre de 24.88%; en

la figura 5, se puede observar el gráfico de confiabilidad, el


139

cual muestra la diferencia marcada entre la frecuencia relativa observada y el riesgo predicho.

Fig. 4. Confiabilidad para la estimación de riesgo de falla en estudiantes de

Ciencias Computacionales que tomaron materias en el término académico 2013-II usando el modelo propuesto.

Fig. 5. Confiabilidad para la estimación de riesgo de falla, usando regresión

logística, en estudiantes de Ciencias Computacionales que tomaron materias en el término académico 2013-I.

Para el segundo semestre del 2013, en la predicción mediante Regresión Logística, se pudo observar un score de Brier , un score de skill , con una

, una , y una incertidumbre de 24.99%; en la figura 6, se puede apreciar la diferencia entre frecuencia relativa observada y el riesgo predicho.

Fig. 6. Confiabilidad para la estimación de riesgo de falla, usando regresión

logística, en estudiantes de Ciencias Computacionales que tomaron materias en el término académico 2013-II.

VI. CONCLUSIONES El uso de prototipos difusos propuesto como clasificador

no-supervisado para la predicción del rendimiento en estudiantes de pre-grado, mediante el pronóstico de riesgo de

reprobación, con base en la historia académica de estudiantes similares, utiliza algoritmos de clustering difuso para la construcción de prototipos dentro de un conjunto de datos, mediante la semejanza y disimilitud entre los elementos de dicho conjunto, este proceso permite identificar los elementos más típicos del conjunto o prototipos, los cuales pueden ser usados en un clasificador no-supervisado para definir la similitud con nuevos datos y asociar un valor de riesgo.

La validación en el proceso de clustering permite estimar el número de clusters, en los casos en que no se conoce el número de categorías dentro de un conjunto de datos, y sea difícil visualizar la distribución de los datos en cada cluster.

Cada una de las categorías, definidas en el proceso de validación, depende de las características o atributos que son seleccionados, o extraídos de cada elemento del conjunto de datos, puesto que estos además de aportar a la semántica de los prototipos construidos, también describe la distribución de los elementos dentro de cada cluster.

En este caso los atributos usados permitieron describir el rendimiento de los estudiantes y la carga académica a la que se enfrentaban, y así definir la similitud entre estudiantes en el proceso de clustering, así como asociar cada cluster a una tasa de reprobación para generalizarla a nuevos datos clasificados, como un valor de riesgo de reprobación.

Con la arquitectura propuesta se diseñó un prototipo, el cual permitió predecir el riesgo de falla en el rendimiento de estudiantes de pre-grado en la carrera de Ingeniería en Ciencias Computacionales, esto con una certeza superior al 75% en cada uno de los términos académicos del año 2013, en el que fue probado, permitiendo a los estudiantes tomar decisiones más educadas en el proceso de selección de materias a registrarse, con base en la predicción del riesgo de reprobación.

Como estrategia a futuro, se espera incorporar otros factores como la carga extra-universitaria, información demográfica y socioeconómica, para mejorar la precisión del modelo de predicción; además la medición de las habilidades ganadas, que definen el rendimiento académico, está en función de las materias en la malla curricular de los estudiantes cuyos datos fueron usados en el caso de estudio, por lo que otra estrategia a futuro sería la descripción del rendimiento, mediante extracción de variables, de manera independiente a la carrera en la que el estudiante se encuentre.

REFERENCIAS

[1] V. McGaha, and J. Fitzpatrick, “Personal and social contributors to dropout risk for undergraduate students”, College Student Journal, vol. 39 no. 2, 2005, pp. 287.

[2] B. K. Bhardwaj, and S. Pal, “Data Mining: A prediction for performance improvement using classification”, arXiv preprint arXiv: 1201.3418, 2012.

[3] M. Pandey and S. Taruna. "A Comparative Study of Ensemble Methods for Students' Performance Modeling." International Journal of Computer Applications, vol. 103 no. 8, 2014.

[4] V. Oladokun, A. Adebanjo, and O. Charles-Owaba. "Predicting students’ academic performance using artificial neural network: A case study of an engineering course." The Pacific Journal of Science and Technology, vol. 9 no. 1, 2008, pp. 72-79.

[5] S. A. Naser, I. Zaqout, M. A. Ghosh, R. Atallah and E. Alajrami, “Predicting Student Performance Using Artificial Neural Network: in the Faculty of Engineering and Information Technology”, International Journal of Hybrid Information Technology, vol. 8 no. 2, 2015, pp. 221-228.

[6] L. Kaufman, and P. J. Rousseeuw. “Finding groups in data: an introduction to cluster analysis”, vol. 344, John Wiley & Sons, 2009.


140

[7] J. C. Bezdek, “Pattern recognition with fuzzy objective function algorithms”, Kluwer Academic Publishers, 1981.

[8] M. Rifqi, “Constructing prototypes from large databases”, In International conference on Information Processing and Management of Uncertainty in knowledge-based systems, IPMU'96, 1996, pp. 301-306.

[9] M. Rifqi, V. Berger, and B. Bouchon-Meunier, “Discrimination power of measures of comparison”. Fuzzy sets and system 110 no. 2, 2000, pp. 189-196.

[10] A. J. Smola and B. Schölkopf, “Learning with kernels”. GMD-Forschungszentrum Informationstechnik, 1998, pp. 210.

[11] M. J. Lesot, “Similarity, typicality and fuzzy prototypes for numerical data”, In 6th European Congress on Systems Science, Workshop Similarity and resemblance, vol. 94, 2005, pp. 95.

[12] M. J. Lesot, M. Rifqi, and B. Bouchon-Meunier, “Fuzzy prototypes: From a cognitive view to a machine learning principle”, In Fuzzy Sets and Their Extensions: Representation, Aggregation and Models, Springer Berlin Heidelberg, 2008, pp. 431-452.

[13] J. C. Bezdek, R. Ehrlich, and W. Full, “FCM: The fuzzy c-means clustering algorithm”, Computers & Geosciences 10 no. 2, 1984, pp. 191-203.

[14] W. Wang, and Y. Zhang, “On fuzzy cluster validity indices”, Fuzzy sets and systems 158 no. 19, 2007, pp. 2095-2117.

[15] R. N. Dave, “Validating fuzzy partitions obtained through c-shells clustering”, Pattern Recognition Letters 17, no. 6, 1996, pp. 613-623.

[16] J. A. Suykens and J. Vandewalle, “Least squares support vector machine classifiers”, Neural processing letters, 1999, pp. 293-300.

[17] T. Runkler, “Selection of appropriate defuzzification methods using application specific properties”, Fuzzy Systems, IEEE Transactions on, vol. 5 no. 1, 1997, pp. 72-79.

[18] J. P. Caulkins, P. D. Larkey, and J. Wei, “Adjusting GPA to reflect course difficulty”, 1996.

[19] G. Méndez, X. Ochoa and K. Chiluiza, “Techniques for data-driven curriculum analysis”, In Proceedins of the Fourth International Conference on Learning Analytics and Knowledge. ACM, 2014, pp. 148-157.

[20] L. R. Fabrigar and D. T. Wegener, “Exploratory factor analysis”, Oxford University Press, 2011.

[21] G. W. Brier, “Verification of forecasts expressed in terms of probability”. Monthly weather review, vol.78 no. 1, 1950, pp. 1-3.

[22] A. H. Murphy, “A new vector partition of the probability score”. Journal of Applied Meteorology, vol. 12 no. 4, 1973, pp. 595-600.

[23] Jr, D. W. Hosmer, S. Lemeshow and R. X. Sturdivant, “Applied logistic regression”, vol. 398, John Wiley & Sons, 2013.

[24] M. J. Lesot, Mouillet, and B. Bouchon-Meunier, “Fuzzy prototypes based on typicality degrees. In Computational Intelligence, Theory and Applications”. Springer Berlin Heidelberg, 2005, pp. 125-138.

[25] R. Krishnapuram, and J. M. Keller, “A possibilistic approach to clustering”. Fuzzy Systems, IEEE Transactions, 1993, pp. 98-110.

Aníbal Vásquez. Recibió la Ingeniería en Ciencias Computacionales en la ESPOL en 2015. Actualmente es Ayudante de investigación en el programa de Tecnologías para la Enseñanza y el Aprendizaje en el Centro de Tecnologías de Información en la ESPOL. Enrique Peláez. Recibió la Ingeniería en Electricidad en la ESPOL en 1989, M.S. in Electrical and Computer Engineering en University of South Carolina en 1991 y el título de PhD. in Electrical and Computer Engineering en University of South Carolina en 1994. Actualmente es Director del Centro de investigación en

Tecnologías de Información en la ESPOL y profesor de postgrado en el área de Inteligencia Computacional de la Facultad de Ingeniería en Electricidad y Computación de la ESPOL.

Xavier Ochoa. Recibió la Ingeniería en Computación en la ESPOL en 2000, M.S. in Applied Computer Science en Free University of Brussels en 2002 y el título de PhD. in Engineering por la Catholic University of Leuvenolina en 2008. Actualmente es Director del programa de Tecnologías para la Enseñanza y el Aprendizaje en

el Centro de Tecnologías de Información en la ESPOL y profesor de postgrado en la Facultad de Ingeniería en Electricidad y Computación.

Dieste, O., Fonseca, E., Raura, G., Rodríguez, P. 2015. Efectividad del Test-Driven development: Un Experimento Replicado. Revista Latinoamericana de Ingeniería de Software, 3(3): 141-147, ISSN 2314-2642

141

Efectividad del Test-Driven Development: Un Experimento Replicado

Oscar Dieste Escuela Técnica Superior de Ingenieros Informáticos

Universidad Politécnica de Madrid Madrid, España

[email protected]

Efraín R. Fonseca C., Geovanny Raura, Priscila Rodríguez Departamento de Ciencias de la Computación Universidad de las Fuerzas Armadas ESPE

Sangolquí, Ecuador {rfonseca, jgraura, pprodriguez2}@espe.edu.ec

Resumen—Los métodos ágiles y sus prácticas asociadas, e.g.: Test-Driven Developement (TDD), son ampliamente utilizadas en la industria y han sido repetidamente sometidas a estudios empíricos. Antecedentes: Se han realizado diversos experimentos en empresas y academia acerca de TDD. En general, los experimentos no muestran un efecto positivo de TDD en la calidad del código o la productividad de los programadores. Objetivo: Replicar el experimento UPM 2014 efectuado por N. Juristo y su equipo, para reproducir sus resultados y secundariamente, estudiar el efecto de la experiencia del desarrollador en la efectividad de TDD. Método: Replicación experimental manteniendo similares el training y los materiales del experimento original. La replicación fue llevada a cabo en la Universidad de las Fuerzas Armadas ESPE sede Latacunga (ESPEL). Los sujetos experimentales fueron 17 estudiantes del Master en Ingeniería de Software. Resultados: Los resultados de la replicación confirman los efectos observados en UPM 2014. La efectividad de TDD ha resultado menor que ITL, aunque las diferencias no son significativas. La productividad y calidad del código producido por los estudiantes ESPEL cuando utilizan ITL y TDD es comparable a la de los estudiantes UPM, aunque menor en valores absolutos. Conclusiones: TDD no produce beneficios en calidad o productividad, o al menos no de forma inmediata. Parece necesario que los sujetos experimentales reciban training intensivo para que los efectos de TDD sean evidentes.

Palabras Clave—Test-Driven Development, TDD, Experimen-tación, Ingeniería de Software

I. INTRODUCCIÓN Desde su introducción en la década de los 90’s, las

metodologías ágiles han venido ganando adeptos y, hoy en día, se configuran como una de las aproximaciones más utilizadas para desarrollar software [1]. Las metodologías ágiles se basan en una serie de prácticas, tales como la programación por pares o el desarrollo dirigido por pruebas (TDD, por sus siglas en inglés) que prometen aumentar la calidad del producto software y la productividad de los programadores. Para comprobar dichas promesas, se han realizado múltiples estudios empíricos, los cuales ponen de manifiesto que estas prácticas pueden ser en ocasiones perjudiciales (por ejemplo: la programación por pares puede reducir la productividad) [2]. Asimismo, existe un buen número de aspectos que matizan o moderan la calidad y la productividad, tales como la complejidad del producto o la experiencia de los desarrolladores.

TDD también ha sido objeto de múltiples estudios empíricos. Una reciente revisión sistemática [3] sugiere que TDD no posee efecto alguno, ni positivo ni negativo, sobre la productividad. Esto contrasta fuertemente con las opiniones de los evangelistas [4]. Adicionalmente, y a diferencia de la práctica de programación por pares, pocos estudios empíricos

han estudiado posibles variables moderadoras (por ejemplo: la experiencia de los programadores, antes citada).

Las limitaciones en el conocimiento científico acerca de TDD han propiciado que algunos investigadores lleven a cabo estudios experimentales en TDD. A este respecto, N. Juristo y su equipo de la Universidad Politécnica de Madrid (UPM) han iniciado una línea de investigación, en el marco de la cual vienen realizando experimentos en distintas universidades y empresas. Este artículo reporta la replicación de uno de los experimentos realizados en UPM en Marzo de 2014. Esta replicación se llevó a cabo en la Universidad de las Fuerzas Armadas ESPE Sede Latacunga (ESPEL) en Ecuador en Mayo 2014. De acuerdo a la tipología propuesta por Gómez et al. [5], esta replicación puede ser clasificada como literal, conjunta y externa. El propósito de llevar a cabo la replicación fue verificar los resultados del experimento original y secundariamente, estudiar el efecto de la experiencia del desarrollador en la efectividad de TDD.

Los resultados de la replicación están en línea con los efectos observados en el experimento original. El uso de TDD no ha logrado aumentar la productividad de los programadores ni la calidad del código. Por el contrario, tanto la productividad como la calidad han sufrido una acusada caída una vez que los sujetos experimentales han comenzado a aplicar TDD. Esto no se ha observado en el experimento original con estudiantes. Finalmente, la tarea experimental parece ser el elemento que más influye en la productividad y calidad resultantes, tanto en el experimento original como en la replicación.

El presente artículo está organizado de acuerdo a las guías de Carver [6], simplificadas para adaptarse al espacio disponible. En la sección II, se presentan los antecedentes y trabajos relacionados. La información acerca del experimento original se incluye en la Sección III. Las diferencias entre el experimento original y la replicación se indican en la Sección IV. La comparación de los resultados de la replicación versus los del experimento original se muestran en la Sección V. Finalmente, se presentan las conclusiones de la investigación.

II. ANTECEDENTES Y TRABAJOS RELACIONADOS Test-Driven-Development (TDD) [4] es una técnica que

cobra fuerza alrededor del manifiesto ágil publicado por un grupo de practicantes de software [7], como parte de la metodología de desarrollo Xtreme Programming (XP) [8] y propone que en lugar de realizar algún diseño o modelo de software, se debe enfrentar el desarrollo en base a la generación de pruebas unitarias antes de la generación efectiva del código.


142

El proceso de TDD consiste de los siguientes pasos: En primer lugar una característica o requerimiento de usuario es seleccionado. A partir de ello, se escribe una prueba que cumpla una tarea pequeña o un pedazo de la característica o requerimiento de usuario (por ejemplo, un método o parte de la funcionalidad incluida en un método); esto produce una prueba que falla. A continuación, se escribe el código de producción que implementa la funcionalidad a ser probada. Una vez implementada la funcionalidad se ejecutan de nuevo las pruebas, así como todas las pruebas anteriores o preexistentes. Si alguna prueba falla se corrige el código de producción y el conjunto de pruebas se vuelve a ejecutar. Si las pruebas pasan se re-factoriza tanto el código de producción como las pruebas para que posean la mayor calidad como sea posible.

Este proceso se contrasta con la técnica de Test Last Development (TLD), que es habitualmente utilizada en los proyectos de desarrollo tradicionales. En TLD, se escribe en primer lugar el código, luego se escriben las pruebas, se ejecutan las pruebas y si fallan se corrigen los errores y se vuelven a ejecutar las pruebas. La figura 1, muestra el proceso de TDD, frente a TLD.

Fig. 1 Proceso de TDD frente a TLD (figura tomada de [9])

Entre las ventajas de TDD, de acuerdo a Beck [4], se consideran a la mejora en la comprensión del código, la eficiencia para encontrar el problema cuando se hallan nuevos defectos, la generación de bancos de pruebas que pueden incrementarse a medida que avanza el desarrollo y la posibilidad de reducir defectos introducidos en el código durante el mantenimiento y depuración.

Los estudios sobre la efectividad de TDD han sido sintetizados en diferentes revisiones sistemáticas de literatura [10], [11], [3], [12], [13] y [14]. Estas revisiones reportan que los estudios primarios se han efectuado tanto en la industria (la menor parte) como en el ámbito académico, utilizando para ello diferentes métodos de investigación (experimentos, casos de estudio, estudios piloto, o encuestas). Aunque los factores analizados son varios, es de nuestro interés el análisis de la calidad y de la productividad.

En cuanto a la calidad, la figura 2 muestra los efectos positivos, negativos o neutros de TDD, reportados en la revisión sistemática de Mäkinen & Münch [14] sobre 19 publicaciones.

Como se observa en la Figura 2, existen atributos de calidad que han sido menos o más estudiados (la mantenibilidad ha sido un aspecto poco estudiado, en tanto que el esfuerzo es uno de los aspectos más estudiados). Se reporta además que la mayoría de estudios presentan resultados

inconclusos o no concluyentes en diferentes aspectos investigados.

Fig. 2 Efectos de TDD en los atributos de calidad (Figura tomada de [14])

Estos resultados en general son similares a los hallazgos encontrados en [11], [10] y [3] donde además se puede notar que existe una tendencia a pensar que TDD mejora la calidad externa, sin embargo la calidad interna y la productividad presentan diferentes conclusiones.

Así podemos encontrar que, en la revisión sistemática de Kollanus [14], se analizan 40 artículos que incluyen 25 experimentos, 14 casos de estudio y una encuesta. Se reporta que hay una evidencia débil de que TDD mejora la calidad externa y que hay pruebas moderadas de que TDD disminuye la productividad. Los resultados son mucho más contradictorios si se toma en cuenta el tipo de investigación (por ejemplo, la mayoría de experimentos controlados no encuentran diferencia en la calidad externa). La evidencia sobre la calidad interna, conlleva también a resultados contradictorios.

En la revisión sistemática de Turhan et al. [11] se reunieron estudios de la industria y el mundo académico entre 2000 y 2008 y el panorama general es que los efectos del TDD son apenas demostrables. En 32 estudios primarios publicados en 22 artículos, se concluye que la calidad externa parece que se mejora específicamente cuando se analizan los datos obtenidos de estudios piloto y de estudios en la industria. En experimentos controlados los resultados no son concluyentes. Aunque en términos generales la evidencia sugiere que TDD puede mejorar la calidad externa. En cuanto a la productividad, al parecer mejora cuando se analizan datos de experimentos controlados. Sin embargo, los estudios piloto proporcionan evidencia mixta, algunos en favor y otros en contra de TDD. En los estudios en la industria, la evidencia indica que TDD disminuye la productividad, por lo que en forma general se puede indicar que los resultados no son concluyentes en este aspecto.

Shull et al. [10], resume los resultados de Turhan et al. [11] y concluye que existe moderada evidencia de que TDD mejora la calidad externa. En cuanto a la productividad los resultados difieren drásticamente en diferentes tipos de estudio. Los experimentos tienden a favorecer a TDD, en tanto que los estudios industriales tienden a favorecer el enfoque tradicional; finalmente los estudios de caso tienen resultados mixtos. Estos resultados además son contrastados con la opinión de expertos.

El meta-análisis de Rafique y Misic [3] con 27 estudios empíricos publicados hasta febrero de 2011, determina que en general, TDD tiene un pequeño efecto positivo en la calidad externa, pero poco o ningún efecto discernible sobre la productividad. En un análisis de subgrupos (estudios académicos y estudios industriales) se ha encontrado que la mejora de la calidad externa y caída de la productividad es mucho más grande en la industria, en comparación con los


143

estudios académicos; sin embargo no hay evidencia concreta que relacione la experiencia con la mejora de la calidad.

Munir [10] concluye que estudios de mayor rigor y relevancia muestran resultados de que TDD mejora en la calidad externa, pero parece que esto genera una pérdida de la productividad. Se encuentra además que estudios de menor rigor no muestran ninguna diferencia; y por lo tanto sostiene que estos hallazgos deben justificarse por un mayor número de experimentos en la industria y estudios de caso longitudinales.

La tabla 1 resume por orden cronológico los resultados de las revisiones sistemáticas citadas (los estudios que informaron sobre la calidad interna son omitidos). También se observa que Shull et al. [10] (*) resume la resultados de Turhan et al. [11], por lo que se muestra como un único estudio ya que sus conclusiones son similares.

TABLA 1. EFECTOS DE TDD EN LA CALIDAD EXTERNA Y PRODUCTIVIDAD DE ACUERDO A DIFERENTES ESTUDIOS.

Revisión Año Calidad Externa Productividad Kollanus

[14] 2010 Experimento controlado: Sin

diferencia Estudios de caso: Mejora

Otros: Mejora PROMEDIO: Mejora

Experimento controlado: No concluyente

Estudios de caso: reducción Otros: Mejora

PROMEDIO: Reducción Turhan et al. [11]

(*) Shull et al [10]

2010 Experimento controlado: no concluyente

Estudios piloto: Mejora Industria: Mejora

PROMEDIO: Mejora

Experimento controlado: mejora Estudios piloto: no concluyente

Industria: Disminución PROMEDIO: No Concluyente

Rafique & Misic [3]

2013 Experimento académico: sin diferencia

Industria: Mejora Test Last: Mejora

Iterative Test-Last: no concluyente (potencial disminución) PROMEDIO: Mejora

Experimento académico: mejora Industria: disminución Test Last: disminución Iterative Test-Last: no

concluyente (potencial mejora) PROMEDIO: No concluyente

Munir et al. [9]

2014 Estudios de Alto Rigor y Alta Relevancia (A): Mejora

Estudios de Bajo Rigor y alta Relevancia (B1): Mejora

Estudios de Alto Rigor y baja Relevancia (B2): sin diferencia Estudios de Bajo Rigor y Baja

Relevancia (C) : no concluyente PROMEDIO: Mejora

Estudios de Alto Rigor y Alta Relevancia (A): disminuye

Estudios de Bajo Rigor y alta Relevancia (B1): disminuye

Estudios de Alto Rigor y baja Relevancia (B2): sin diferencia Estudios de Bajo Rigor y Baja

Relevancia (C) : no concluyente PROMEDIO: No concluyente

En síntesis podemos indicar que los estudios citados

reportan diferentes resultados sobre los efectos de TDD en la calidad externa, la calidad interna y la productividad dependiendo de los grupos y subgrupos investigados, rigor y relevancia de los métodos de investigación utilizados, y otros factores que en general no han permitido llegar a conclusiones sólidas.

Creemos que lo que subyace en los resultados aparentemente contradictorios sobre la efectividad de TDD es una falta de consideración de las características personales de los sujetos como pueden ser: la experiencia y el conocimiento previo en TDD, su habilidad para realizar casos de pruebas, el conocimiento del dominio, la motivación, entre otros; sin que se evidencien estudios significativos sobre estos aspectos hasta la actualidad.

III. INFORMACIÓN ACERCA DEL EXPERIMENTO ORIGINAL El experimento original fue realizado por N. Juristo y su

equipo en el marco del proyecto ESEIL1. El objetivo de este experimento fue estudiar la efectividad de TDD en comparación con Iterative Test-Last (ITL). ITL es la aproximación más usada para el desarrollo de software apoyado por test automatizados. ITL consiste en el desarrollo

1 Empirical Software Engineering Industrial Lab, por sus siglas en inglés. La información acerca de los experimentos realizados está disponible en https://sites.google.com/site/fidiproeseil/

de pequeñas porciones del código de producción, seguido inmediatamente por la realización de pruebas de unidad [15].

A. Factores y Variable Respuesta El experimento original ensayó como factor principal la

aproximación de desarrollo, con los niveles ITL y TDD. Se usó como factor secundario la tarea que los sujetos debían resolver. La tarea tuvo cuatro niveles, que correspondían con cuatro katas2 ampliamente usados en experimentos acerca de TDD: MarsRover (MR), MusicPhone (MP), BowlingScoreKeeper (BSK) y Sudoku (SDKU). La web del proyecto ESEIL contiene la descripción de dichas tareas.

La efectividad de la aproximación de desarrollo (ITL y TDD) puede ser estudiada desde varias perspectivas. En el experimento original se han estudiado dos variables: la calidad externa (QLTY) y la productividad (PROD), junto con otras variables no relevantes para este trabajo. QLTY representa el grado de corrección del código desarrollado por los sujetos, y se define como:

(1)

donde QLTYi es la calidad de la historia de usuario i-ésima

implementada por el sujeto. QLTYi se define como:

(2)

mientras que #TUS es:

(3) En ambos casos, #Asserti(Pass) representa el número de

aserciones de jUnit (ya que el experimento se realizó utilizando el lenguaje de programación Java) correctamente ejecutados en la historia de usuario i-ésima. PROD representa la cantidad de trabajo realizada por los sujetos, y se define como:

(4)

B. Hipótesis El experimento original posee dos hipótesis

experimentales; la primera hace referencia a que la calidad del producto software no se ve alterada por el uso de ITL o TDD:

H10: QLTYITL = QLTYTDD H11: QLTYITL <> QLTYTDD Mientras que la segunda hipótesis afirma lo mismo respecto

a la productividad: H20: PRODITL = PRODTDD H21: PRODITL <> PRODTDD

C. Diseño Debido al previsible reducido número de sujetos

experimentales, los investigadores originales decidieron utilizar un diseño de medidas repetidas para aumentar el poder estadístico [8,9]. Dicho diseño se muestra en la Tabla 2. Este diseño puede calificarse como ABBB, ya que el nivel de interés (TDD) se aplica repetidas veces para mejorar las habilidades de los sujetos y poder detectar más fácilmente sus efectos. El factor secundario tarea fue contrabalanceado en las

2 Las katas corresponden a la especificación y código base de programas muy

conocidos en el ámbito de TDD, usados como objetos experimentales


144

cuatro sesiones experimentales para evitar confundir los factores tarea y aproximación de desarrollo.

TABLA 2. DISEÑO EXPERIMENTAL Secuencia Temporal

Sesión 1 Sesión 2 Sesión 3 Sesión 4 ITL TDD-1 TDD-2 TDD-3

D. Amenazas a la Validez Los diseños de medidas repetidas poseen generalmente las

siguientes amenazas a la validez [16]: fatiga, práctica, carry over y orden/periodo. En el presente experimento operó sin duda la amenaza de fatiga, ya que las sesiones son contiguas en el tiempo. Sin embargo, creemos que las restantes amenazas no aplican, por las siguientes razones:

Práctica: TDD es una aproximación nueva para la mayoría de los sujetos experimentales. Para poder identificar los potenciales efectos beneficiosos de TDD, los sujetos deben lograr cierto grado de pericia. Por lo tanto, la práctica obtenida mediante la aplicación repetida del nivel TDD no representa una amenaza a la validez sino una condición necesaria para alcanzar los objetivos experimentales.

Carry over: ITL utiliza estrategias parecidas a TDD, por lo que el carry-over, al igual que la práctica, resulta favorable para el experimento.

Orden/periodo: Las sesiones experimentales son contiguas en el tiempo. Descontados los efectos de práctica y carry-over, no existe ninguna razón que sugiera la existencia de un efecto de orden/periodo.

E. Ejecución del Experimento Original El experimento original se realizó en academia, utilizando

como sujetos experimentales 16 estudiantes de maestría de la UPM. Antes de realizar el experimento se aplicó un cuestionario demográfico, cuyos resultados se muestran en la Tabla 3 de forma simplificada. Todos los sujetos poseen titulaciones relacionadas con la informática (Ingeniero de Sistemas y Computación, o similar), y una experiencia profesional media-baja (menor a 4 años, con pocas excepciones). En la actualidad, ninguno de los sujetos se encuentra trabajando en industria. Todos han usado lenguajes procedurales y orientados a objetos. A pesar de la poca experiencia, la inmensa mayoría de los sujetos han realizado labores de programación en la industria. Un 50% de los sujetos reportan poseer experiencia intermedia en programación. La mayoría de los sujetos conocen Java, aunque no pruebas de unidad ni jUnit. Tres sujetos reportan haber usado TDD como metodología de desarrollo por un breve lapso de tiempo.

El experimento original se realizó en la UPM en el mes de Marzo de 2014. La duración total del experimento fue de 5 días, realizándose sesiones experimentales a partir del segundo día. Para la realización del experimento se utilizó el lenguaje de programación Java y jUnit 4.

La descripción detallada de los resultados del experimento original está disponible en el sitio web del proyecto ESEIL3 En lo que sigue reportaremos únicamente los resultados principales con el objetivo de permitir la comparación del experimento original y la replicación en la Sección III literal F.

El experimento original ha sido incapaz de obtener efectos significativos de la aproximación de desarrollo tanto para la variable respuesta calidad como productividad, si bien en esta última se aprecia una cierta tendencia a la significación

3 https://sites.google.com/site/_diproeseil/

estadística (p-valor = 0.116). Por el contrario, se ha podido constatar la influencia de la tarea tanto en calidad como en productividad (p-valor < 0.000 en ambos casos). La Figura 3 muestra el gráfico de perfil para la variable respuesta calidad, mientras que la Figura 4 muestra la misma información para la productividad. Se observa claramente que, para ambas variables respuesta, las tareas BSK y SDKU registran más altas cotas de calidad y productividad que las tareas MP y SDKU.

TABLA 3. DATOS DEMOGRÁFICOS.

Experiencia ID Profesional

(4 años) ¿Prog.

Profesional? Programación Java

3 4 años Si Novice Novice 4 4 años Si Intermediate Intermediate 5 1.15 años Si Intermediate Novice 6 . Si Intermediate Intermediate 7 2 años Si Novice Novice 8 0.5 años Si Intermediate Intermediate 9 No 10 1.5 años Si 12 6 años No 13 0.15 años Si Novice Novice 14 2 años Si Novice Intermediate 15 4 años Si Intermediate Intermediate 16 10 años Si Intermediate Intermediate 17 6 años Si Intermediate Novice 20 14 años Si 21 12 años Si Intermediate Novice

NOTA: Las celdas con un ‘.’ corresponden a datos no reportados por los sujetos. Todas las celdas en blanco corresponden con el valor “Sin experiencia”. La experiencia se valora de la siguiente forma: No experience=0-2 años; Novice=2-5 años; Intermediate=5-10 años; Expert>10 años.

Fig. 3 Gráfico de perfil (variable respuesta calidad)

IV. INFORMACIÓN ACERCA DEL LA REPLICACIÓN La replicación fue realizada en la Universidad de las

Fuerzas Armadas ESPE de Ecuador - Sede Latacunga (ESPEL en lo que sigue), en el marco del curso de Verificación y Validación de Software de la Maestría en Ingeniería de Software. El experimento consistió en realizar ejercicios en la práctica, que fueron evaluados como parte de la asignatura.�


145

Fig. 4 Gráfico de perfil (variable respuesta productividad)

A. Motivación para la Realización de la Replicación La razón principal que motivó la realización de la

replicación fue conformar los resultados del experimento original o, en el caso de encontrar diferencias, identificar los factores o parámetros que podrán haber causado las desviaciones. Asimismo, esperamos que la realización de replicaciones nos permita identificar qué influencia ejerce el programador, en función de su experiencia (novato, profesional, etc.) en la efectividad de las estrategias ITL y TDD. No obstante, no esperamos que la presente replicación arroje resultados al respecto, siendo necesarios más experimentos para identificar efectos con relativa seguridad.

B. Nivel de Interacción con los Experimentadores Originales La replicación fue guiada por uno de los experimentadores

originales (O. Dieste) durante todo el ciclo experimental, tanto en la fase de entrenamiento como en la colección de datos y análisis. La replicación puede calificarse como literal (es decir, la replicación se asemeja al experimento original tanto como sea posible), conjunta (algunos de los experimentadores originales participaron en la replicación) y externa (la replicación se llevó a cabo en un sitio diferente) [17].

C. Cambios Respecto al Experimento Original En general, la replicación se llevó a cabo de acuerdo al

experimento original en todos los aspectos. Las hipótesis, factores, variables respuesta, materiales, procedimiento experimental no fueron cambiados. La población experimental fue muy similar (estudiantes de postgrado, de la UPM en el experimento original y de la ESPE en la replicación). La orientación general de la docencia también fue muy similar, aunque en el experimento original el profesor fue B. Turham (de la Universidad de Oulu, Finlandia) y en la replicación el profesor fue O. Dieste (UPM).

La única diferencia, y aun así no sustancial, reside en el diseño experimental. El experimento original tuvo una duración de 5 días, por lo que fue posible realizar 4 sesiones experimentales, lo que resultó en un diseño ABBB (ver Sección II literal C). La replicación tuvo una duración de 4 días, lo que exigió eliminar una de las sesiones TDD. El diseño de la replicación fue ABB. Las amenazas a la validez son las mismas del experimento original (ver Sección III literal D).

D. Ejecución de la Replicación 17 estudiantes tomaron parte en el experimento. Sus datos

personales se obtuvieron, de forma previa al experimento, mediante una encuesta implementada en Google Forms. La información demográfica se muestra en la Tabla 3. Todos los sujetos poseen titulaciones relacionadas con la informática. La experiencia profesional parece asimismo considerable, aunque no todos los sujetos han reportado dicha información. En lo tocante a las habilidades en programación, todos los sujetos han usado lenguajes procedurales y orientados a objetos (por brevedad, el detalle se ha omitido de la Tabla 3). No obstante, un 50% de los sujetos se califican a sí mismos como sin experiencia o novatos en programación, lo cual va habitualmente unido al hecho de que no han trabajado como programadores en la industria. La mayoría de los sujetos desconoce Java, pruebas de unidad y jUnit. Ninguno de los sujetos recibió formación específica en TDD con anterioridad al experimento, aunque uno de ellos (#3) reporta haber usado TDD en entornos ágiles durante 1 año.

El experimento se realizó en paralelo con un curso en Verificación y Validación. La duración total del curso es de 32 horas, divididas en cuatro sesiones presenciales de 8 horas de jueves a domingo. Durante cada sesión se impartió docencia acerca de prueba de unidad, ITL y TDD. La docencia estuvo apoyada por ejercicios prácticos. Las sesiones experimentales tuvieron lugar de Viernes a Domingo, en horario de mañana. Esta agenda fue respetada sin que tuvieran lugar desviaciones relevantes.

Los sujetos #12 y #13 no entregaron sus soluciones a las tareas experimentales, probablemente a causa de su pobre desempeño, el cual pudo ser observado por los experimentadores durante la realización de las sesiones experimentales. El sujeto #22 tampoco entregó sus soluciones, aunque su desempeño fue aparentemente satisfactorio.

E. Resultados En lo que respecta a la aproximación de desarrollo ITL

supera a TDD-1 y TDD-2 tanto en calidad como en productividad. En lo tocante a las tareas, BSK alcanza las mayores cotas de calidad y productividad, seguido por SDKU, MP y, finalmente, MR. Las dispersiones son notables tanto para la aproximación de desarrollo como para la tarea. En muchos casos, la mediana de los niveles se sitúa en cero. Esto implica que varios sujetos han tenido dificultades para solucionar los problemas planteados. El diseño experimental exige la aplicación de un análisis de medidas repetidas.

Debido a la complejidad del diseño y a la existencia de covariables, el método estadístico más apropiado es un modelo mixto. Hemos especificado como factores fijos la aproximación de desarrollo y la tarea, así como su interacción. La aproximación de desarrollo se ha incluido también como factor aleatorio en el análisis, para modelar los efectos de aprendizaje. Esto es posible, ya que el orden de realización de las sesiones y la aplicación de los tratamientos están confundidos. Como covariables, se ha añadido la experiencia en programación y la experiencia en pruebas de unidad, que parecen ser los dos aspectos en los que los sujetos experimentales se diferencian en mayor medida (ver Tabla 3). La estructura de covarianzas escogida ha sido AR(1), la cual es a menudo adecuada para experimentos realizados en intervalos temporales consecutivos. Los resultados del análisis se muestran en la Fig. 5 y Fig. 6 para la calidad y productividad, respectivamente.


146

Los residuos de modelo son normales tanto para la productividad como para la calidad (test Shapiro-Wilks, p-valores 0.215 y 0.071 respectivamente). Los resultados del modelo mixto son, pues, confiables. El factor aproximación de desarrollo ha resultado no significativo, así como también la interacción aproximación de desarrollo por tarea, y las covariables experiencia en programación y la experiencia en pruebas de unidad. No pueden descartarse errores de tipo II debido al reducido número de sujetos experimentales.

En contrapartida, el factor tarea ha resultado significativo para las dos variables respuesta. En lo que respecta a la productividad, la comparación por pares indica que BSK >SDKU >MR (p-valores 0.0009 y 0.04, respectivamente). En lo tocante a la calidad, BSK >MP y BSK >MR (p-valores 0.011 y 0.004, respectivamente).

Fig. 5 Modelo mixto (variable respuesta calidad)

Fig. 6 Modelo mixto (variable respuesta productividad)

La gran diferencia existente entre BSK y las restantes tareas experimentales es incluso más evidente en los gráficos de perfil que se muestran en las Figuras 7 y 8.

Fig. 7 Gráfico de perfil (variable respuesta calidad)

Fig. 8 Gráfico de perfil (variable respuesta productividad)

F. Comparación de Resultados Considerando que la replicación es del tipo literal respecto al

experimento original, los resultados son comparables en todos sus aspectos y coincidentes en su mayor parte. Ni el experimento original ni la replicación fueron capaces de obtener efectos significativos de la aproximación de desarrollo tanto para la variable respuesta calidad como productividad. En lo que respecta a la tarea, los resultados son significativos en ambos casos, y con unas tendencias muy similares. BSK y SDKU obtienen mayores valores de productividad y calidad que MP y MR, aunque SDKU en ESPEL se destaca menos que en el experimento original.

La mayor diferencia entre ambos experimentos son los valores absolutos de las variables respuesta. Los datos de ESPEL son claramente más bajos que en UPM. Esta situación no es nueva, ya que en experimentos anteriores realizados en ESPEL [18] los resultados han mostrado una tendencia similar. La razón del menor rendimiento podría deberse a las características de la población (los sujetos UPM exhiben mayor experiencia de programación que ESPEL), así como a problemas de motivación y cansancio por el carácter intensivo del curso en ESPEL.

Finalmente, se observa una caída muy fuerte de productividad y calidad en ESPEL el primer día que los sujetos aplicaron TDD. (TDD-1) Esto no ocurre en UPM. La productividad y calidad aumentan en TDD-2. Ello podría indicar la necesidad de mayor entrenamiento.

V. CONCLUSIONES TDD no produce beneficios en calidad o productividad, o al

menos no de forma inmediata. Parece necesario que los sujetos experimentales reciban training intensivo para que los efectos de TDD sean evidentes. Se necesita una mayor cantidad de evidencias empíricas para establecer con seguridad los efectos de TDD.

REFERENCIAS [1] B. Cartaxo, A. Araujo, A. Sa Barreto y S. Soere, «The impact of

scrum on customer satisfaction: An empirical study,» Software Engineering (SBES), pp. 129-136., 2013.

[2] J. E. Hannay, T. Dyba, E. Arisholm y D. I. S, «The effectiveness of pair programming: A meta-analysis Information and Software Technology,» special Section: Software Engineering for Secure Systems Software Engineering for Secure Systems., vol. 51, nº 7, p. 1110 – 1122, 2009.


147

[3] Y. Rafique y V. Misic, «The Effects of Test-Driven Development on External Quality and Productivity: A Meta-Analysis,» Software Engineering, IEEE Transactions, vol. 39, nº 6, p. 835–856, 2013.

[4] K. Beck, Test Driven Development: By Example, Addison-Wesley Professional, 2002.

[5] J. C. Carver, «Towards reporting guidelines for experimental replications: A pro- posal,» Proceedings of the 1st International Workshop on Replication in Empir- ical Software Engineering Research (RESER), 4 May 2010.

[6] B. e. al., «agilemanifesto.org,» 2001. [En línea]. Available: http://agilemanifesto.org/. [Último acceso: 12 Agosto 2014].

[7] K. Beck y A. Cynthia, Extreme Programming Explained: Embrace Change., Addison-Wesley Professional., 2004.

[8] M. Hussan, M. Misagh y P. Kai, «Considering rigor and relevance when evaluating test driven development: A systematic review.,» Information and Software Technology, vol. 56, pp. 375-394, 2014.

[9] F. Shull, G. Melnik, B. Turhan, L. Layman, M. Diep y H. Erdogmus, «What do we know about test-driven development?,» IEEE Software, vol. 27, nº 6, pp. 16-19, 2010.

[10] B. Turhan , L. Layman , M. Diep , H. Erdogmus y F. Shull, «How Effective is Test-Driven Development?,» Making Software: What Really Works, and Why We Believe It, pp. 399-412, 2010.

[11] H. Munir y M. Moayyed , «Systematic Literature Review and Controlled Pilot Experimental Evaluation of Test Driven Development (TDD) vs.Test-Last Development (TLD),» 2012.

[12] A. Causevic, D. Sundmark y S. Punnekkat, «Factors Limiting Industrial Adoption of Test Driven Development: A Systematic Review,» Software Testing, Verification and Validation (ICST), 2011 IEEE Fourth International Conference, pp. 337-346, 21-25 Marzo 2011.

[13] M. Simo y M. Jürgen , «Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies,» Software Quality. Model-Based Approaches for Advanced Software and Systems Engineering, vol. 166, pp. 155-169, 2014.

[14] B. George y L. Williams, «An initial investigation of test driven development in industry.,» Proceedings of the 2003 ACM symposium on applied computing, pp. 1135-1139 , 2003.

[15] D. Janzen y H. Saiedian, «On the Influence of Test-Driven Development on Software Design,» Software Engineering Education and Training, pp. 141-148, 2006.

[16] T. Cook y D. Campbell, Quasi-Experimentation: Design & Analysis Issues for Field Settings, Boston: Houghton Mifflin, 1979.

[17] O. S. Gómez Gómez, «Tipología de Replicaciones para la Síntesis de Experimentos en Ingeniería del Software,» de Ph.D. dissertation, Universidad Politécnica de Madrid, 2012.

[18] R. E. Fonseca, E. G. Espinosa y O. Dieste, «Effectiveness for detecting faults within and outside the scope of testing techniques: An independent replication,» Empirical Software Engineering, vol. 18, nº 15, pp. 1-40, 2013.

Oscar Dieste. Es investigador científico de la Universidad Politécnica de Madrid. Anteriormente, fue becario Fulbright con la Universidad de Colorado en Colorado Springs y profesor asistente con las universidades Complutense de Madrid y de Alfonso X el Sabio. Sus intereses de investigación incluyen: la

ingeniería de software empírica, la ingeniería de requisitos y sus intersecciones. Recibió su B.S. en Informática en la Universidad de La Coruña y su Ph.D. en la Universidad de Castilla-La Mancha

Efraín R. Fonseca C. Se recibió como doctor en julio de 2014 en la Universidad Politécnica de Madrid. Tiene diez años de experiencia como consultor en la industria de las TI. Es profesor investigador a tiempo completo en la Universidad de las Fuerzas Armadas ESPE de Ecuador. Entre sus temas de investigación de interés están: el

proceso experimental en ingeniería de software, métodos de investigación en ingeniería de software, análisis y diseño orientado a objetos y representaciones ontológicas en ingeniería de software.

Geovanny Raura. Es Ingeniero de Sistemas e Informática con un grado de maestría en Ingeniería de Software obtenido en la Universidad Politécnica de Madrid. Es profesor investigador a tiempo completo en la Universidad de las Fuerzas Armadas - ESPE de Ecuador y Candidato a Phd. por la Universidad Nacional de La Plata de

Argentina. Entre sus temas de investigación de interés están la ingeniería de software empírica, la ingeniería de requisitos, y técnicas de desarrollo de software basadas en metodologías ágiles.

Priscila Rodríguez. Es Ingeniera en Sistemas Informáticos de la Escuela Superior Politécnica de Chimborazo ESPOCH, cuenta con cinco años de experiencia en la industria de desarrollo de software bancario, obtuvo una Maestría en Gerencia de Proyectos de Ingeniería en la

Universidad de Melbourne - Australia, actualmente se desempeña como Docente Tiempo Completo de la Universidad de las Fuerzas Armadas ESPE. Entre sus temas de investigación de interés están eGovernment, y el uso de metodologías para la Planificación Estratégica de Tecnologías de la Información.

Mario G. Almache C., Jenny A. Ruiz R., Geovanny Raura, Efraín R. Fonseca C. 2015. Modelo Neuronal de Estimación para el Esfuerzo de Desarrollo en Proyectos de Software (MONEPS)


148

Modelo Neuronal de Estimación para el Esfuerzo de Desarrollo en Proyectos de Software (MONEPS)

Mario G. Almache C, Geovanny Raura, Jenny A. Ruiz R., Efraín R. Fonseca C. Universidad de las Fuerzas Armadas ESPE

Sangolquí, Ecuador [email protected]

Resumen—La estimación temprana del esfuerzo para la construcción de un producto software, es crucial en la previsión del costo y tiempo necesarios para su desarrollo. Los modelos y técnicas para la estimación del esfuerzo presentan como principal inconveniente, la poca precisión en las predicciones realizadas y generalmente se hace una mínima consideración de los aspectos no funcionales del software. Se propone la construcción de un modelo de estimación para el esfuerzo en el desarrollo de software denominado MONEPS, que pretende mejorar la precisión en la estimación del esfuerzo, utilizando una Red Neuronal Artificial (RNA) en Backpropagation, cuya capa de entrada se estructura sobre la base de un conjunto de características y atributos tomados de la norma ISO/IEC 25000 de la calidad del software. La RNA fue entrenada con datos recopilados de aplicaciones desarrolladas en el ámbito académico, de las cuales se conocían sus tiempos de desarrollo y costos asociados. Las estimaciones de tiempo y costo, para dos casos de prueba, muestran más precisión en el modelo neuronal, en comparación con los modelos Cocomo-81 y Cocomo-II. MONEPS ha logrado la convergencia de aspectos funcionales y no funcionales para mejorar la precisión en la estimación del esfuerzo en proyectos de software.

Palabras Clave—Software, Inteligencia Artificial, Redes Neuronales, Estimación del Esfuerzo.

I. INTRODUCCIÓN La estimación del esfuerzo es un aspecto de particular

importancia en la elaboración de los proyectos de software [1]. Las pequeñas y medianas empresas de software se enfrentan al desafío de seleccionar, de una parte, el método de estimación más adecuado para su contexto, y de otra parte, adoptar mejores prácticas que permitan consolidar una base histórica de estimación, con el propósito de disminuir cada vez más la brecha entre los valores estimados y los valores reales [2].

La estimación del esfuerzo para el desarrollo de software es una actividad compleja y de poca precisión en los resultados obtenidos [3], lo que ha ocasionado la aparición de varias herramientas comerciales para la estimación de costos del software, tales como [4]: Cocomo-II [5], CoStar [6], CostModeler [7], CostXpert [8], KnowledgePlan® [9], SEER [10], y SoftCost-R [11]. Por otra parte, existen algunas herramientas de estimación de costos que están tendiendo a la obsolescencia [12], debido principalmente a su temprana aparición; así tenemos: CheckPoint [13], ESTIMACS [14], REVIC [15] y SPQR/20 [16].

El número de herramientas existentes no significa que la problemática de la estimación del esfuerzo en proyectos de software haya sido solventada favorablemente, al contario ésta se ha incrementado, debido principalmente a la falta de mantenimiento de las herramientas y modelos disponibles [17].

En el presente artículo se presenta una propuesta de Modelo Neuronal de Estimación para el Esfuerzo de Desarrollo en Proyectos de Software (MONEPS), utilizando una RNA en Backpropagation, cuya capa de entrada se basa en un conjunto de atributos de naturaleza funcional y no funcional tomados de la norma de calidad del software ISO/IEC 25000 [18]. Esta RNA fue entrenada con datos de aplicaciones desarrolladas en el ámbito académico, de las que se conocían el tiempo empleado para su desarrollo y los costos asociados. La evaluación de MONEPS se llevó a cabo sobre dos aplicaciones específicas, obteniéndose mejoras significativas en las predicciones de tiempo y costo, en relación a los modelos Cocomo-81 [19] y Cocomo-II [20]. Este resultado evidencia la convergencia de los aspectos funcionales y no funcionales para mejorar la precisión en la estimación del esfuerzo en este tipo de aplicaciones.

El documento está organizado de la siguiente manera: En la Sección II se pone de manifiesto la importancia de mejorar la precisión en la estimación de proyectos de software. También se describen las principales categorías de los modelos de estimación para el esfuerzo, enfatizando en las técnicas de inteligencia artificial y en el modelo Cocomo-II. La Sección III presenta la propuesta neuronal para la estimación del esfuerzo en el desarrollo de proyectos de software, y se muestran los resultados obtenidos en la fase de entrenamiento de la RNA. En la Sección IV se muestra el desempeño de MONEPS cuando sus resultados son comparados con aquellos calculados a través de los modelos Cocomo-81 y Cocomo-II. Finalmente, en la Sección V, se mencionan las principales conclusiones de esta investigación y el trabajo futuro.

II. ANTECEDENTES A. Necesidad de mejorar la precisión en la estimación del

esfuerzo El estado actual del arte evidencia, por una parte, una falta

de consenso al momento de seleccionar los atributos para la concepción de los modelos sobre los que se implementan las herramientas de estimación de software; por otra parte, las relaciones causales entre los atributos y el esfuerzo, tampoco están claras, lo cual se aprecia en la insatisfacción de los usuarios respecto a los resultados de estimación obtenidos [21].

Los resultados de la estimación del esfuerzo en software siguen siendo aún muy distantes de los valores reales, lo que conduce a reflexionar acerca del grado de adecuación que se consigue con las herramientas de estimación disponibles, respecto a las necesidades particulares de los diferentes tipos de proyectos [22].

Como se puede notar, la tarea de estimar esfuerzo en software no está exenta de dificultades; los modelos y

Mario G. Almache C., Jenny A. Ruiz R., Geovanny Raura, Efraín R. Fonseca C. 2015. Modelo Neuronal de Estimación para el Esfuerzo de Desarrollo en Proyectos de Software (MONEPS) Revista Latinoamericana de Ingeniería de Software, 3(3): 148-154, ISSN 2314-2642

149

herramientas de estimación tradicionales enfrentan algunos problemas, como los que a continuación se exponen.

El principal inconveniente de los modelos predictivos basados en líneas de código (p.e. del tipo Cocomo), es que las líneas de código no pueden medirse hasta que el sistema esté completo [23]. Además, los modelos genéricos como Cocomo fallan a la hora de realizar ajustes de la predicción sin calibración. La necesidad de calibración se confirma en los estudios de Kemerer [24], Kitchenham & Taylor [25] y Low & Jeffery [26]. La poca atención de los aspectos no funcionales del software ha sido otra característica de los modelos predictivos para estimar el esfuerzo [27].

Frente a las dificultades que presentan los modelos tradicionales de estimación, han surgido nuevos enfoques que proponen la utilización de las técnicas de inteligencia artificial para mejorar las predicciones del esfuerzo; así podemos mencionar:

El clustering [28] es utilizado en la estimación del software para salvar el inconveniente de los modelos paramétricos que utilizan una única ecuación que representa a toda una base de datos de proyectos. Mediante el clustering los proyectos de software son divididos en grupos homogéneos, de tal manera que, un nuevo proyecto será asociado al grupo con el que tenga más coincidencias. Este enfoque requiere la disponibilidad de un gran conjunto de datos para establecer los grupos.

Chiu & Huang [29, 30] proponen mejorar la estimación del esfuerzo basados en analogía, con la ayuda de algoritmos genéticos y medidas de distancias (p.e. Euclidea, Manhattan, y Minkowski) entre parejas de proyectos. Este modelo calcula una distancia entre el proyecto de software que se estima y cada uno de los proyectos de software históricos, y a continuación, recupera el proyecto más similar para generar una estimación de esfuerzo. Luego, un algoritmo genético ajusta el esfuerzo reutilizado en función de las distancias de similitud entre pares de los proyectos. Los algoritmos genéticos, en general, requieren muchos recursos de cómputo para procesar las posibles soluciones.

Kumar [31] utilizó redes neuronales para predecir el esfuerzo en software con la ayuda de funciones de transferencia de Morlet y Gaussiana; estas funciones tienen un buen desempeño en RNA con más de dos capas ocultas. Más específicamente se utilizaron dos redes neuronales: WNN (Wavelet Neural Network) y TAWNN (Threshold Accepting Trained Wavelet Neural Network). Datos experimentales mostraron un mejor desempeño en la configuración WNN.

Jodpimai [32] hace una propuesta neuronal para predecir el esfuerzo, basado en la reducción de características del modelo Cocomo-81. La propuesta consta de tres pasos: a) preparación de datos tomados de dominios públicos; b) reducción del número de características, considerando sólo aquellas relevantes; c) transformar el problema de la estimación de esfuerzo del software en un problema de clasificación y aproximación funcional mediante el uso de una red neuronal en cascada. Lamentablemente, el modelo Cocomo-81 no ha podido acoplarse satisfactoriamente a la dinámica del software.

En el 2011, García [33] hace una propuesta neuronal para estimar el tiempo de duración en proyectos de software, recurriendo a un subconjunto de datos obtenido de la organización International Software Benchmarking Standards Group (ISBSG1); en dicha propuesta se filtró el conjunto de

1 El sitio web de ISBSG está disponible en: http://www.isbsg.org/

características disponibles, excluyendo aquellas referentes al cálculo de puntos de función.

En síntesis, las dificultades de los modelos tradicionales que inciden directamente en la poca precisión de las predicciones, requieren enfoques alternativos que permitan disponer de herramientas actuales y útiles para estimar costos y tiempos en el desarrollo de proyectos software. Esto propició la presente propuesta para la estimación del esfuerzo en software desde una perspectiva neuronal.

B. Modelos y técnicas de estimación para el esfuerzo en

software Las técnicas de estimación, pueden ser clasificadas bajo

tres categorías principales [34]: Juicio del experto: un estimador de proyectos de software usa su experticia para estimar, basado en información histórica y en proyectos similares. El principal inconveniente de esta técnica es la dificultad de estandarización en los criterios de los expertos [35, 36].

Modelos algorítmicos: es la categoría más popular en la literatura. Estos modelos incluyen Cocomo [37], SLIM [38] y SEER-SEM [39]. El factor principal de costo de estos modelos es el tamaño del software, que usualmente está asociado con las líneas de código. Estos modelos usan fórmulas de regresión lineal o también fórmulas de regresión no lineal. La desventaja de estos modelos radica en la necesidad de hacer ajustes a las predicciones, cuando los modelos no están calibrados [40].

Aprendizaje de máquina: actualmente estas técnicas están siendo utilizadas en conjunción con los modelos algorítmicos, o como alternativas a éstos. Las técnicas de aprendizaje de máquina pueden incluir: lógica difusa [41], redes neuronales artificiales [42], minería de datos, sistemas neuro-difusos [43] y algoritmos genéticos [44].

La Tabla I muestra un resumen de las principales ventajas e inconvenientes para los enfoques de juicio del experto y modelos algorítmicos, para la estimación del esfuerzo en software.

TABLA I. PRINCIPALES VENTAJAS Y DESVENTAJAS EN DOS ENFOQUES PARA LA ESTIMACIÓN DEL ESFUERZO EN SOFTWARE

Enfoque Ventajas Inconvenientes Aplicación idónea

Modelos algorítmicos

Entradas y parámetros concretos. Objetividad. Eficiencia en cálculos.

No prestan atención a circunstancias excepcionales. Rechazan opiniones subjetivas.

Proyectos con escasas alteraciones accidentales, con equipos de desarrollo estables y productos sencillos.

Juicio del experto

Gran cantidad de opiniones subjetivas. Consideración de circunstancias excepcionales.

Dependencia de los expertos. Posturas de expertos difíciles de adoptar.

Primeras fases de desarrollo del producto.

Por otra parte, varios modelos de estimación que se han

publicado desde los años 60 han quedado obsoletos [45], así tenemos los modelos de: Aaron (1969), Wolverton (1974), Walston-Feliz (1977), Doty (1977), Putnam (1978), SLIM (1979), entre otros.

Cabe indicar que, el modelo Cocomo-81 (1981) y su actualización Cocomo-II (1997), han ido evolucionando para



150

constituirse como la base de las herramientas de estimación existentes en la actualidad [46].

En el 2012, P.K. Suri y Pallavi Ranjan [47] hacen un análisis de los métodos de estimación desde la década de los 70s, concluyendo que en los últimos 5 años se introdujeron diversos métodos en aras de incrementar la precisión de los resultados, tras la identificación de algunos problemas teóricos (Kitchenham, 2009). Para ello, la tendencia propone combinar diferentes métodos de estimación y utilizar a la par técnicas de inteligencia artificial, entre las que destacan: lógica difusa, sistemas basados en conocimiento y redes neuronales artificiales [48].

Por lo tanto, se cree conveniente aportar con una propuesta neuronal para estimar el esfuerzo de desarrollo en proyectos de software, basada en el uso de la norma ISO/IEC 2500 para la calidad de software. Esta propuesta no tiene una fórmula explícita con coeficientes preestablecidos para el cálculo del esfuerzo; tampoco precisa de líneas de código ni puntos de función (como es el caso del modelo Boehm [49] y el modelo Albretch [50]) en el proceso de estimación del esfuerzo. En contraposición, MONEPS necesita inputs (p.e. número de requisitos funcionales del proyecto, nivel de seguridad requerido, tipo de lenguaje de programación utilizado, etc.) fundamentados en la norma referida anteriormente, para estimar el costo y tiempo de desarrollo de un producto software. A través de MONEPS se muestra el mecanismo predictivo de las RNA's [51] para mejorar la precisión en la tarea de estimar el tiempo y costo para el desarrollo de software.

III. PROPUESTA DEL MODELO NEURONAL DE ESTIMACIÓN PARA EL ESFUERZO DE DESARROLLO EN PROYECTOS DE

SOFTWARE (MONEPS) A. Topología neuronal para MONEPS

La estructura neuronal seleccionada para MONEPS es de tipo Backpropagation. Estas redes neuronales artificiales (ver Figura 1) presentan algunas características [52, 53, 54], las cuales se indican a continuación:

Fig. 1. Ejemplo de una red neuronal en cascada (Backpropagation)

Aprenden de manera supervisada e inductiva. Son suficientes 3 capas (una de entrada, otra oculta, y una de salida) para las tareas de aprendizaje e identificación de patrones.

No tienen mayor complejidad estructural ni algorítmica (lo que no sucede p.e. con las topologías recursivas de redes).

Existe una buena disponibilidad de herramientas automatizadas, tanto libres como propietarias, para el diseño y funcionamiento de estas redes.

Han sido utilizadas y probadas de manera satisfactoria en varios campos de aplicación (p.e. reconocimiento de imágenes, clasificación de patrones, codificación / decodificación de información, etc.).

B. Diseño neuronal de MONEPS Para definir la topología de entrada del modelo neuronal se

consideraron 42 atributos pertenecientes a características del estándar ISO/IEC 250002, que describen varios aspectos para la calidad de un producto software. Estos atributos fueron seleccionados en base a que consideran la tendencia actual hacia la mejora en el desarrollo de software [55]. A modo de ejemplo, en la Tabla II se describen cinco de los cuarenta y dos atributos seleccionados.

TABLA II. TIEMPLOS DE ATRIBUTOS QUE FORMAN PARTE DE LA CAPA DE ENTRADA PARA LA RNA UTILIZADA POR MONEPS

Atributo/Código Valores Descripción

Nivel de seguridad (A#2) Alto, Medio, Bajo

Indica el nivel de seguridad requerido para la aplicación.

Número de programadores (M#3)

1, 2, 3, ...

Número de integrantes del equipo de desarrollo asignados a esta actividad.

Facilidad de navegación (C#1) Alta, Media, Baja

Indica la facilidad requerida para navegar en la aplicación.

Lenguaje de Programación (F#1)

Imperativo, Declarativo, Orientado a Objetos, Orientado al Problema

Tipo de lenguaje de programación utilizado.

Disponibilidad de arquitectos de software (M#2)

0, 1, 2, 3, ... Arquitectos asignados al proyecto.

Por consiguiente, la capa de entrada tendrá en total 42

neuronas, mientras que la capa de salida tendrá solamente 2 neuronas (una para el tiempo y otra para el costo requerido).

En la Figura 2 se muestra un esquema parcial de la RNA utilizada en MONEPS. Como se puede observar en la red, las conexiones unidireccionales van desde la capa de entrada hasta la capa de salida (es decir, no hay ciclos), a través de una capa oculta que tiene 7 neuronas; esta capa posibilita el aprendizaje de la RNA. En la misma figura se muestran algunos atributos de la capa de entrada de la red. Cabe referir que, los atributos pueden ser de naturaleza cuantitativa (p.e. número de programadores asignados) o cualitativa (p.e. experiencia del equipo de desarrollo).

C. Implementación y resultados obtenidos en la fase de entrenamiento de la RNA El diseño de MONEPS fue implementado en la

herramienta JustNN3. Durante la fase de entrenamiento de la RNA fueron utilizados 9 proyectos académicos desarrollados por estudiantes pertenecientes a los últimos niveles de la carrera de Ingeniería en Sistemas e Informática de la Universidad de las Fuerzas Armadas ESPE de Ecuador. De cada uno de los proyectos académicos se obtuvo la información correspondiente a los 42 atributos de entrada de

2 El sitio web de esta norma está disponible en: http://iso25000.com/ 3 Las caracteristicas de JustNN están disponibles en: http://www.justnn.com/


151

la RNA; así por ejemplo, se disponía de información como: nivel de seguridad, tiempo de respuesta requerido, nivel de escalabilidad de la aplicación, entre otros. Para poder estructurar las dos salidas de la RNA, se utilizó el tiempo de desarrollo y costo de cada proyecto académico referido.

Fig. 2. RNA en Backpropagation usada en MONEPS

El funcionamiento de la RNA es similar al de una caja negra (en este caso con 42 entradas y 2 salidas); es decir, dentro de la caja negra la red aprende a configurar patrones de entrada/salida, actualizando los valores de los denominados “pesos sinápticos” o “conexiones neuronales”, lo cual es transparente para el usuario. Luego del entrenamiento de la RNA utilizando la herramienta JustNN, se pudo constatar que la red tuvo un desempeño satisfactorio después de 44 ciclos (o épocas) de aprendizaje (ver Figura 3).

Fig. 3. Resultados obtenidos durante la fase de entrenamiento de la RNA

El error de la red durante la fase de entrenamiento estuvo en el orden del 0.5 %, lo que denota un rendimiento muy aceptable en relación al mínimo error requerido que es del 1.0%. En consecuencia, la red aprendió rápidamente a configurar patrones de comportamiento para tiempos y costos

referidos a proyectos de software, lo que se puede ver en la Figura 4.

Fig. 4. Variación del error máximo, mínimo y medio durante el entrenamiento

de la red

Adicionalmente, la Figura 5 muestra la importancia relativa (en valor porcentual) de cada atributo de entrada en la RNA. Por ejemplo, la disponibilidad de un arquitecto de software (atributo M#2) no es muy importante; al contrario, la facilidad de navegación (atributo C#1) es muy importante en la determinación del esfuerzo en los proyectos académicos.

Fig. 5. Importancia relativa de cada atributo en la RNA

IV. EVALUACIÓN DEL MODELO El desempeño de la RNA de MONEPS está dado

principalmente por su carácter predictivo, es decir, la capacidad de responder ante casos que no ha visto. En tal virtud, se estudiaron tres proyectos académicos de software; dos de éstos formaron el conjunto de prueba (proyectos académicos de software que no fueron considerados en la fase de entrenamiento de la RNA).

En la fase de evaluación, la RNA fue consultada sobre el tiempo y costo de desarrollo de los tres proyectos académicos referidos, para lo que se ingresaron (por cada proyecto) los 42



152

datos que precisa la red en su capa de entrada. Los resultados obtenidos de la evaluación se muestran en la Tabla III.

TABLA III. TIEMPO Y COSTO ESTIMADO PARA 2 CASOS DE PROYECTOS QUE LA RED NO HA VISTO. *TAMBIÉN SE PRUEBA CON UN EJEMPLO DE

ENTRENAMIENTO

El primer proyecto evaluado corresponde a un simulador

para la evaluación de aptitudes de aspirantes para el desarrollo de software, denominado Codesoft. El segundo proyecto es un sistema de facturación. El tercer proyecto se refiere a un sistema para control de fichas odontológicas.

Puede observarse que, los costos y tiempos estimados por MONEPS, son muy cercanos a los costos y tiempos reales. Para una mejor contrastación se ha creído conveniente realizar una comparación de resultados con respecto a los modelos Cocomo-81 y Cocomo-II, lo que se muestra en las Tablas IV y V, respectivamente.

TABLA IV. TIEMPOS ESTIMADOS APLICANDO COCOMO-81

Tiempo (meses) Caso

Real Estimado por Cocomo-81

Estimado por Moneps

1 3.0 6.85 3.65

2 5.0 7.75 3.97

TABLA V. TIEMPOS Y COSTOS ESTIMADOS EN COCOMO-II

Caso Estimado por Cocomo-

II

Estimado por Moneps

Estimado por

Cocomo-II

Estimado por

Moneps

1 12.20 3.65 10371.01 8139.45

2 10.20 3.97 12376.34 7273.05

La comparación con los modelos Cocomo-81 y Cocomo-II,

permite apreciar que MONEPS mantiene una mejor aproximación al tiempo real de duración y costo. En la Tablas VI y VII se muestra el cálculo del error relativo para Cocomo-II, Cocomo 81 y MONEPS.

V. CONCLUSIONES Y TRABAJO FUTURO La RNA utilizada por MONEPS aprendió rápidamente a

configurar patrones de comportamiento para tiempos y costos referidos a proyectos de software, y por ende, las estimaciones realizadas son bastante cercanas a los costos y tiempos reales. Los resultados arrojados por la propuesta neuronal, en la fase de evaluación, mostraron mejor precisión respecto a los modelos Cocomo-81 y Cocomo-II, en la estimación de costo y tiempo para proyectos académicos de software. Más específicamente, el error relativo promedio en tiempo y costo, fue respectivamente, 10 y 3 veces menor en MONEPS con relación a Cocomo-II, para dos aplicaciones de prueba. Por otra parte, el error relativo promedio para el tiempo fue 4 veces

menor en MONEPS con relación a Cocomo-81, para las mismas dos aplicaciones de prueba.

TABLA VI. TABLA VI. ERRORES RELATIVOS EN COCOMO-II Y MONEPS

TABLA VII. ERRORES RELATIVOS EN COCOMO-81 Y MONEPS

Error relativo para el tiempo Caso Nombre del proyecto Cocomo-81 Moneps

1 CODESOFT 128.33% 21.67%

2 FACTURACIÓN 55.00% 20.60%

La RNA tiene sus entradas fundamentadas en el uso de

atributos del estándar ISO/IEC 25000, para la calidad de software. La asociación directa de estos atributos con la capa de entrada de la RNA, ayudó a simplificar la información que alimentó el modelo neuronal. El criterio de diseño para MONEPS, posibilitó la convergencia de aspectos funcionales y no funcionales en la estimación temprana de tiempo y costo para el desarrollo de proyectos de software de tipo académico. Sin embargo, es necesario validar la propuesta neuronal en otros proyectos de software fuera del ámbito académico.

MONEPS es de fácil uso y escalable; se pueden realizar los ajustes necesarios para mejorar el nivel de adecuación y precisión en la naturaleza dinámica del software. Tales ajustes se refieren básicamente a activar/desactivar atributos de entrada, y también a la alimentación de la RNA con datos de nuevas aplicaciones.

Como trabajo futuro se vislumbra la identificación de nuevos atributos críticos y métricas especializadas para los aspectos no funcionales, que podrían incidir notablemente en el nivel de precisión para las estimaciones realizadas por la propuesta neuronal. Asimismo, se pretende más adelante, añadir un componente fuzzy (difuso) para realizar interpretaciones lingüísticas de las entradas y respuestas obtenidas (sistemas neuro-difusos).

AGRADECIMIENTOS Queremos expresar nuestro más profundo agradecimiento a

todas aquellas personas que contribuyeron con su valioso aporte al desarrollo del presente trabajo. En especial a los estudiantes de los últimos niveles pertenecientes a la Carrera de Ingeniería en Sistemas e Informática en la Universidad de las Fuerzas Armadas ESPE. Agradecemos también los importantes comentarios y opiniones de los distinguidos docentes de la mencionada Carrera, en especial a los Ingenieros: Carlos Montenegro, Danilo Martínez, Raúl Córdova y Henry Coral.

REFERENCIAS [1] Diaz Villegas, J. E., & Robiolo, G. (2014). Método de

estimación de costos de un producto de software web. In XLIII Jornadas Argentinas de Informática e Investigación Operativa (43JAIIO)-XV Simposio Argentino de Ingeniería de Software (Buenos Aires, 2014).

Caso Tiempo real de duración (meses)

Tiempo estimado (MONEPS)

Costo referencial (USD)

Costo estimado (MONEPS)

1

3.00

3.65

7558.80

8139.45

2

5.00

3.97

8810.00

7273.05

3*

4.00

3.96

7244.00

7797.52

Error relativo para el tiempo

Error relativo para el costo Caso Nombre del

proyecto Cocomo-II Moneps Cocomo-

II Monep

s

1 CODESOFT 306.67% 21.67% 37.20% 7.68%

2 FACTURACIÓN 104.00% 20.60% 40.48% 17.45%


153

[2] Moløkken-Østvold, K., Jørgensen, M., Tanilkan, S. S., Gallis, H., Lien, A. C., & Hove, S. W. (2004, September). A survey on software estimation in the Norwegian industry. In Software Metrics, 2004. Proceedings. 10th International Symposium on (pp. 208-219). IEEE.

[3] Omaña, M. (2010). Manufactura Esbelta: una contribución para el desarrollo de software con calidad. Enl@ce: revista Venezolana de Información, Tecnología y Conocimiento, 7(3), 11-26.

[4] Pressman, R. (2010). Ingeniería de Software. McGraw-Hill Interamericana de España.

[5] Boehm, B. W., Madachy, R., & Steece, B. (2000). Software cost estimation with Cocomo II with Cdrom. Prentice Hall PTR.

[6] Boehm, B. W., & Valerdi, R. (2008). Achievements and challenges in cocomo-based software resource estimation. Software, IEEE, 25(5), 74-83.

[7] Axelrad, V., Granik, Y., Boksha, V. V., & Rollins, J. G. (1994, September). Cost and yield estimation in a virtual IC factory. In Microelectronic Manufacturing (pp. 102-108). International Society for Optics and Photonics.

[8] Madachy, R. (2007). Distributed global development parametric cost modeling. In Software Process Dynamics and Agility (pp. 159-168). Springer Berlin Heidelberg.

[9] Jones, C. (1996). How software estimation tools work. American Programmer, 9, 18-27.

[10] Madachy, R., & Boehm, B. (2008). Comparative Analysis of COCOMO II, SEER-SEM and True-S Software Cost Models. USC-CSSE-2008-816, University of Southern California Center for Systems and Software Engineering.

[11] Southwell, S. V. (1996). Calibration of the Softcost-R Software Cost Model to the Space and Missile Systems Center (SMC) Software Database (SWDB) (No. AFIT/GSM/LAS/96S-6). AIR FORCE INST OF TECH WRIGHT-PATTERSON AFB OH SCHOOL OF LOGISTICS AND ACQUISITION MANAGEMENT.

[12] Rodríguez, P., Martínez, H. (2010). Modelos Paramétricos de Estimación de Esfuerzo dentro del Proceso de Planificación de Proyectos Software. Revista de Procesos y Métricas, Vol. 7. Asociación Española para la Gobernanza, la Gestión y la Medición de las TI.

[13] Ferens, D. V. (1998, July). The conundrum of software estimation models. InAerospace and Electronics Conference, 1998. NAECON 1998. Proceedings of the IEEE 1998 National (pp. 320-328). IEEE.

[14] Boehm, B., Abts, C., & Chulani, S. (2000). Software development cost estimation approaches - A survey. Annals of Software Engineering, 10(1-4), 177-205.

[15] Webber, B. G. (1995). A Calibration of the Revic Software Cost Estimating Model (No. AFIT/GCA/LAS/95S-13). AIR FORCE INST OF TECH WRIGHT-PATTERSON AFB OH SCHOOL OF LOGISTICS AND ACQUISITION MANAGEMENT.

[16] Cordero Carrasco, R. J. (2013). Una herramienta de apoyo a la estimación del esfuerzo de desarrollo de software en proyectos pequeños (Doctoral dissertation, Universidad de Chile).

[17] Mizell, C., & Malone, L. (2007). A project management approach to using simulation for cost estimation on large, complex software development projects.

[18] International Organization for Standardization & International Electrotechnical Commission. (2005). ISO/IEC 25000, Software product Quality Requirements and Evaluation (SQuaRE).

[19] Boehm, B. (2000). Safe and simple software cost analysis. IEEE software, (5), 14-17.

[20] Baik, J., Boehm, B., & Steece, B. M. (2002). Disaggregating and calibrating the CASE tool variable in COCOMO II. Software Engineering, IEEE Transactions on, 28(11), 1009-1022.

[21] López, J. E., & DOLADO COSÍN, J. J. (2008). Estimación del Esfuerzo Software: Factores vinculados a la aplicación a desarrollar. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, 2(1).

[22] Robiolo, M. G., & Informáticas, C. (2009). Transacciones, Objetos de Entidad y Caminos: métricas de software basadas en

casos de uso, que mejoran la estimación temprana de esfuerzo (Doctoral dissertation, Tesis Doctoral UNLP. http://postgrado. info.unlp.edu.ar/Carrera/Doctorado/Tesis%20Doctorales.html).

[23] Rodríguez, D., Pytel, P., Tomasello, M., Pollo Cattaneo, M. F., Britos, P. V., & García Martínez, R. (2011). Estudio del Modelo Paramétrico DMCoMo de Estimación de Proyectos de Explotación de Información. In XVII Congreso Argentino de Ciencias de la Computación.

[24] Kemerer, C. F. (1987). An empirical validation of software cost estimation models. Communications of the ACM, 30(5), 416-429.

[25] Kitchenham, B. A., & Taylor, N. R. (1984). Software cost models. ICL technical journal, 4(1), 73-102.

[26] Low, G. C., & Jeffery, D. R. (1990). Function points in the estimation and evaluation of the software process. Software Engineering, IEEE Transactions on, 16(1), 64-71.

[27] Hochstetter, J., Diaz, C., & Cares, C. (2012, June). Software call for tenders: Metrics based on speech acts. In Information Systems and Technologies (CISTI), 2012 7th Iberian Conference on (pp. 1-6). IEEE.

[28] Rubio, M. G. (2006). Aplicación de técnicas de clustering para la estimación del esfuerzo en la construcción de proyectos software (Doctoral dissertation, Universidad de Alcalá).

[29] Chiu, N. H., & Huang, S. J. (2007). The adjusted analogy-based software effort estimation based on similarity distances. Journal of Systems and Software, 80(4), 628-640.

[30] Huang, S. J., Chiu, N. H., & Chen, L. W. (2008). Integration of the grey relational analysis with genetic algorithm for software effort estimation. European Journal of Operational Research, 188(3), 898-909.

[31] Kumar, K. V., Ravi, V., Carr, M., & Kiran, N. R. (2008). Software development cost estimation using wavelet neural networks. Journal of Systems and Software, 81(11), 1853-1867.

[32] Jodpimai, P., Sophatsathit, P., & Lursinsap, C. (2010, March). Estimating software effort with minimum features using neural functional approximation. InComputational Science and Its Applications (ICCSA), 2010 International Conference on (pp. 266-273). IEEE.

[33] Garcia, A., Gonzalez, I., Colomo-Palacios, R., Lopez, J. L., & Ruiz, B. (2011). Methodology for software development estimation optimization based on neural networks. Latin America Transactions, IEEE (Revista IEEE America Latina), 9(3), 384-398.

[34] Peralta, M. (2004). Estimación del esfuerzo basada en casos de uso. Reportes Técnicos en Ingeniería de Software. Buenos Aires-Argentina, 6(1), 1-16.

[35] Páez Anaya, I. D. (2012). Estudio empírico del estado actual de la estimación de software en Pymes de Colombia.

[36] Robiolo, G., Castillo, O., Rossi, B., & Santos, S. (2013). Es posible superar la precisión basada en el juicio de expertos de la estimación de esfuerzo de productos de software? X Workshop Latinoamericano de Ingeniería de Software Experimental, ESELAW.

[37] Boehm, B. W. (1981). Software engineering economics (Vol. 197). Englewood Cliffs (NJ): Prentice-hall.

[38] Putnam, L. H. (1978). A general empirical solution to the macro software sizing and estimating problem. IEEE transactions on Software Engineering, 4(4), 345-361.

[39] Galorath, D. D., & Evans, M. W. (2006). Software sizing, estimation, and risk management: when performance is measured performance improves. CRC Press.

[40] Vizcaíno, A., García, F., & Piattini, M. (2014). Visión General del Desarrollo Global de Software. International Journal of Systems and Software Engineering for Big Companies.

[41] Lopez-Martin, C. (2011). A fuzzy logic model for predicting the development effort of short scale programs based upon two independent variables. Applied Soft Computing, 11(1), 724-732.

[42] De Barcelos Tronto, I. F., da Silva, J. D. S., & Sant’Anna, N. (2008). An investigation of artificial neural networks based prediction systems in software project management. Journal of Systems and Software, 81(3), 356-367.



154

[43] Huang, X., Ho, D., Ren, J., & Capretz, L. F. (2007). Improving the COCOMO model using a neuro-fuzzy approach. Applied Soft Computing, 7(1), 29-40.

[44] Afzal, W., & Torkar, R. (2011). On the application of genetic programming for software engineering predictive modeling: A systematic review. Expert Systems with Applications, 38(9), 11984-11997.

[45] Ruíz Constanten, Y., & Cordero Morales, D. (2013). Estimación en proyectos de software integrando los métodos de Boehm y Humphrey. Revista Cubana de Ciencias Informáticas, 7(3), 23-36.

[46] Páez, J. A. (2003). Avances en la toma de decisiones en proyectos de desarrollo de software (Doctoral dissertation, Universidad de Sevilla).

[47] Suri, P. K., & Ranjan, P. (2012). Comparative Analysis of Software Effort Estimation Techniques. International Journal of Computer Applications, 48(21).

[48] Isasi Viñuela, P., & Galván León, I. M. (2004). Redes de Neuronas Artificiales.Un Enfoque Práctico, Editorial Pearson Educación SA Madrid España.

[49] Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., & Selby, R. (1995). Cost models for future software life cycle processes: COCOMO 2.0. Annals of software engineering, 1(1), 57-94.

[50] Albrecht, A. J., & Gaffney Jr, J. E. (1983). Software function, source lines of code, and development effort prediction: a software science validation. Software Engineering, IEEE Transactions on, (6), 639-648.

[51] Attarzadeh, I., Mehranzadeh, A., & Barati, A. (2012, July). Proposing an enhanced artificial neural network prediction model to improve the accuracy in software effort estimation. In Computational Intelligence, Communication Systems and Networks (CICSyN), 2012 Fourth International Conference on (pp. 167-172). IEEE.

[52] Pino Díez, R., Fuente García, D. D. L., Parreño Fernández, J., & Priore Moreno, P. (2002). Aplicación de redes neuronales artificiales a la previsión de series temporales no estacionarias o no invertibles.

[53] Russell, S. J., & Norvig, P. (2009). Artificial Intelligence: A Modern Approach. Third Edition. Prentice Hall.

[54] Warwick, K. (2013). Artificial intelligence: the basics. Routledge.

[55] Pesado, P., Bertone, R. A., Esponda, S., Pasini, A. C., Boracchia, M., Martorelli, S., & Rodriguez Eguren, S. (2012). Planes de

Mejora, Mejora de Procesos de Gestión y Calidad en el desarrollo de Sistemas de Software. In XIV Workshop de Investigadores en Ciencias de la Computación.

Mario G. Almache C. Ingeniero en Informática, graduado en la Universidad Central del Ecuador, 1996. Es docente a tiempo completo en la Universidad de las Fuerzas Armadas ESPE, Ecuador. Sus áreas principales de interés para investigación son: machine learning, modelado matemático y simulación de sistemas dinámicos.

Jenny A. Ruiz R. Ingeniera en Sistemas e Informática, graduada en la Universidad Técnica de Ambato, Ecuador 1998. Con una maestría en Informática de la misma Universidad. Es docente a tiempo completo en la Universidad de las Fuerzas Armadas ESPE, Ecuador. Entre sus temas de investigación están: ingeniería de software,

ingeniería de requisitos, estimación de proyectos de software.

Geovanny Raura. Es Ingeniero de Sistemas e Informática con un grado de maestría en Ingeniería de Software. Es profesor investigador a tiempo completo en la Universidad de las Fuerzas Armadas ESPE de Ecuador. Entre sus temas de investigación de interés están la ingeniería de software empírica, la ingeniería de requisitos, y técnicas de desarrollo

de software basadas en metodologías ágiles

Efraín R. Fonseca. Se recibió como Doctor en julio de 2014. Tiene diez años de experiencia como consultor en la industria de las TI. Es profesor investigador en la Universidad de las Fuerzas Armadas ESPE de Ecuador. Entre sus temas de investigación de interés están: el proceso

experimental en ingeniería de software, métodos de investigación en ingeniería de software empírica, análisis y diseño orientado a objetos y representaciones ontológicas en ingeniería de software.

REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE

Documents

Transcript of REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE