M an tenibilidad y Evolutividad en el S o ftw are
Libre y de Código A bierto
Trabajo Final Integrador para la obtención del título de Especialista en
Ingeniería de Software
Autor:
Jorge Ramirez Morales
Director:
M.Sc. Gustavo Gil
Co-director:
Dr. Gustavo Rossi
Universidad Nacional de La Plata
r
Indice de contenido
Introducción...
Trabajos Previos... Estructura del informe...
1.- Mantenimiento y Evolución del Software...
1.1 Mantenimiento y evolución del software... 1.1.1 Definiciones de Mantenimiento y Evolución del Software Cambios en el software después de la entrega... Similitudes y diferencias entre evolución y mantenimiento. 1.1.2 Definiciones y Dificultades de la Mantenibilidad... 1.1.3 Evolución y Evolutividad... Leyes de la Evolución del Software... Evolutividad... 4 .6 6 8 ..9 1 J. 14 16 18 2.~ Medición de la mantenibilidad y la evolutividad...20
2.1 Métricas de Software... 21
2.1.2 Medición de la mantenibilidad... 22
2.2 Mantenibilidad y Evolutividad en la bibliografía genera) sobre mètri -2.2.1 Mantenibilidad en Fenton y Pfleeger...23
Vista externa de la mantenibilidad... 23
Atributos internos que afectan la mantenibilidad... 24
2.2.2 Kan: Métricas del proceso de mantenimiento...24
Tiempo de respuesta de corrección y reactividad de corrección. 25 Porcentaje de correcciones demoradas... 25
Calidad de corrección... 26
Efectividad de la remoción de defectos... 26
La efectividad en la remoción de defectos vista de cerca... 27
2.2.3 Tian: Prevención de defectos y mejora de procesos... 28
Análisis de las causas raíz para la prevención de defectos...29
Clasificación y análisis de errores... 29
Tipos generales de análisis de defectos...29
Análisis de distribución de defectos...30
Observaciones generales... 30
Análisis de tendencias de defectos y modelos dinámicos de defectos... 31
2.4 La Complejidad del Software... 38
2.4.1 La Complejidad Ciclomática... 41
2.4.2 Ciencia del software de Halstead... 42
2.4.3 Complejidad y Acoplamiento... 43
2.5 Métricas y Orientación a Objetos... 44
2.5.1 Métricas CK... 45
2.5.2 Las métricas MOOD... 46
2.6 Estudios Empíricos...49
2.6.1 Métricas, Validación y Predicción... 49
2.6.2 Algunos estudios empíricos... 49
2.6.3 Limitaciones de la validez de los trabajos empíricos...53
Umbrales y Valores atípicos...54
Métricas y “Bad Smells”... 55
Caracterización y Evaluación...57
2.7 Evaluación de productos mediante métricas 0 0 ... 58
3.- Mantenibilidad, evolutividad y F/OSS... 60
3.1 F/OSS y Calidad de Software...61
3.2 Relevamiento de información de proyectos F/OSS...62
3.2.1 Dificultades para el relevamiento de información...62
3.3 Investigación cuantitativa... 63
3.4 Evaluación de F/OSS a partir del código...66
3.4.1 Análisis de la evolución de Sweet Home 3D...67
Conclusiones... 70
El presente trabajo parte del objetivo general de elaborar criterios para evaluar aspectos técnicos de productos F/OSS (Software Libre y de Código Abierto) como posibles bases o componentes para el desarrollo de aplicaciones.
Una de las características más importantes de este tipo de software es la disponibilidad pública del código; en muchos casos, además, también se dispone de amplia informa ción sobre .el desarrollo del producto. Las licencias bajo las cuales se distribuyen habi- tualmente los productos F/OSS no sólo habilitan sino que alientan a la reutilización y/o modificación de las aplicaciones.
Al momento de plantearse el desarrollo con F/OSS, sin embargo, es frecuente encontrar que la información pública de la cual se dispone es incompleta, deficitaria o desaotualí- zada[36][65]; además, nada sabemos a priori respecto de la facilidad o dificultad que supondrá realizar cambios en un código desarrollado por una comunidad[87][79].
Estos aspectos representan limitaciones de peso para la reutilización del F/OSS. Resulta necesario, entonces, desarrollar modelos, criterios y herramientas que permitan evaluar las características de productos y proyectos F/OSS, y al mismo tiempo proveer a la comunidad de desarrollo de elementos que posibiliten atender la demanda de mantenibi- lidad[73].
Por otra parte, los productos F/OSS más extendidos se caracterizan por la continua adi ción de nuevas funcionalidades, adaptación a nuevos entornos y corrección de erro res [26]; estas características implican una constante evolución del F/OSS, entendida como necesidad de que el software sufra modificaciones para seguir utilizándose en el tiempo[49].
La posibilidad de adaptar un producto de F/OSS para una necesidad particular o de inte grarlo a un nuevo desarrollo supone considerar las dificultades que la evolución del pro ducto pudiera plantear.
Desde el punto de vista del reuso de aplicaciones para desarrollo de software, las carac terísticas que se vinculan con la mantenibilidad y la evolutividad constituyen elementos de valoración esenciales para la selección de programas y componentes.
con claridad los conceptos de manteniminento y evolución y, derivados de ellos, los de mantenibilidad y evolutividad.
Estos atributos también son de carácter complejo, por lo que diversos autores han pro puesto diferentes desagregaciones en atributos menores susceptibles de ser medidos. Estos conjuntos de atributos y sus relaciones con los conceptos que nos interesan consti tuyen modelos de mantenibilidad y evolutividad.
Trabajos Previos
El presente trabajo se vincula con el Proyecto de Investigación 1690 ‘‘Desarrollo de un enlomo virtual de enseñanza-aprendizaje para la Universidad Nacional de Salta*', del Consejo de Investigación de la Universidad Nacional de Salta, bajo la dirección del M. Se. Gustavo Gil.
Ya en el año 2007, integrantes del proyecto estimaron el esfuerzo que insumiría el desa rrollo de una plataforma educativa como Moodle[67], partiendo del código fuente de esa aplicación.
Posteriomiente, el estudio de la información disponible en repositorios F7OSS llevó a buscar indicadores de la utilización del seguimiento de errores en proyectos de ese tipo[66], con miras a evaluar el desempeño de proyectos de ese tipo respecto de la información y corrección de errores.
Estructura del informe
En la primera parte relevaremos críticamente diversas definiciones de mantenimiento y evolución, enfatizando los aspectos problemáticos. Comenzaremos reviendo bibliogra fía de carácter general sobre Ingeniería de Software y sobre temas vinculados al mante nimiento y la evolución.
En la segunda sección revisaremos modelos de evolutividad y mantenibilidad, desta cando el punto de vista desde el cual se proponen y su posible relevancia respecto de la evaluación de estos atributos en productos F/OSS.
En tercer lugar presentamos un recorrido de propuestas de medición de los atributos mencionados, tanto desde perspectivas teóricas como empíricas, enfatizando las caracte-________ Mantenibilidad y Evolutividad en el Software Librea de Código Abierto
rísticas que a nuestro entender les otorgan importancia o validez para nuestro objetivo. En la cuarta sección discutiremos las posibilidades y limitaciones de la utilización de la información públicamente accesible en proyectos F/OSS y analizaremos la validez o la utilidad de las propuestas relevadas en la sección anterior que consideremos más ade cuadas para nuestros objetivos, en virtud de datos recogidos empíricamente de la infor mación pública de proyectos F/OSS.
Finalmente, presentaremos nuestras conclusiones y los trabajos a realizar en el futuro. ________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
1
.- M a n t e n im ie n t o y
1.1 Mantenimiento y evolución del software
Los productos de software suelen sufrir modificaciones aún después de terminados o entregados. Estas variaciones pueden deberse a cambios en los requerimientos, modifi caciones en la propia organización para la cual está destinado, necesidades de adapta ción o fallas de funcionamiento.
Cualquiera sea la causa, el costo de producir las modificaciones en cuestión es general mente elevado; no existe un consenso general respecto de la incidencia del manteni miento en los costos de desarrollo, pero diversas estimaciones y estudios[27] lo ubican entre el 60% y el 90% del total invertido a lo largo de la vida de un producto de soft ware.
Estos porcentajes pueden resultar sorprendentes desde una perspectiva intuitiva de la noción del mantenimiento, al que suele considerarse limitado a la corrección de errores; en el software las tareas de mantenimiento comprenden la adecuación del producto a las modificaciones en el entorno en el que debe desempeñarse (por ejemplo, adopción de una nueva plataforma de software o de hardware), cambios o agregados respecto de los requerimientos originales, etc.[49].
En definitiva, los productos de software debe modificarse necesariamente para poder seguir satisfaciendo la necesidad que les da origen en entornos organizacionales y tec nológicos que varían. Esta característica del software se conoce como evolutividad (evolvability) y constituye un área de investigación de interés creciente. [49] [55]
No existe acuerdo general respecto del conjunto de atributos que inciden en las dificul tades de mantenimiento, ni sobre la forma de evaluarlos; no obstante, existen numero sos trabajos que aportan perspectivas diferentes, a veces parciales o acotadas, y que es necesario cotejar para conformar una mirada abarcativa de las posibilidades y dificulta des actuales.
1.1.1 Definiciones de Mantenimiento y Evolución del Software
En la guía para el cuerpo de conocimiento de la Ingeniería de Software [1] se define al Mantenimiento como un área de conocimiento de la Ingeniería de Software que com
prende las actividades a realizar a lo largo de todo el ciclo de vida del software; si bien la fase de mantenimiento comienza una vez entregado el producto de software, las tareas de mantenimiento se inician mucho antes.
La guía mencionada retoma el estándar IEEE 1219 (estándar para el mantenimiento de software), donde se detine al mantenimiento como “la modificación de un producto de software posterior a su entrega, con el fin de mejorar su performance u otros atributos, o para adaptarlo a un nuevo entorno".
En el glosario de terminología de la Ingeniería de Software de la IEEE[37] se define a! mantenimiento como “el proceso de modificar después de su entrega un sistema de soft ware o un componente para corregir errores, mejorar su performance u otros atributos o adaptarlo a un entorno modificado'’.
La visión del mantenimiento sustentada en estas definiciones se orienta principalmente a las actividades posteriores a la entrega del software, pese a las advertencias menciona das en la guía SWEBOK[l].
Weiderman y otros[84], en un informe técnico del CMU/SEI, enfocan estos términos no sólo respecto del software sino en relación al sistema en el que opera. Estos autores diferencian Mantenimiento del Software (entendido como intervenciones de grano fino, a corto plazo y cambios localizados) frente a Evolución del Sistema (de grano más grueso, de alto nivel, una forma estructural de cambio que facilita el mantenimiento del software).
Sommerville[77] destaca que el software sufre modificaciones en sus requerimientos una vez que ya está en funcionamiento; el cliente o usuario puede advertir con el uso la necesidad de que el software incorpore nuevas prestaciones, o los cambios en los nego cios, en el dominio o en el entorno pueden obligar a que el software sufra cambios para continuar prestando servicios. Esos cambios constituyen la evolución del software.
Para Sommerville, cuando la transición entre el desarrollo y las modificaciones no es continua, se aplica el término mantenimiento.
El mismo autor pone de relieve otras connotaciones que diferencian los dos términos en cuestión cuando se refieren al software. Denomina mantenimiento al proceso general de
________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto cambiar el software una vez entregado, resaltando que la expresión se aplica especial mente cuando los equipos de desarrollo encargados de la modificación son diferentes a les desarrolladores originales.
Endres y Rombach[19] adoptan definiciones sencillas, aunque acotadas, tanto de mante nimiento como de evolución. Sostienen que evolución es el término que designa la adaptación de sistemas en funcionamiento a nuevos requerimientos; en tanto, manteni miento se refiere a la actividad relativa a la eliminación de fallas.
Mens[55] observa que las nociones reflejadas en los estándares mencionados se asocia al ciclo de vida en cascada propuesto por Royce, y se orienta según una visión afín a la de las prácticas industriales; así, la idea de mantenimiento se refiere principalmente a la corrección de errores y pequeños ajustes, a realizarse luego de la entrega del software. Sin embargo, los productos de software se desarrollan para satisfacer una determinada necesidad y cumplir con una serie de requerimientos que corresponden a un momento determinado de una organización; con el tiempo, el ambiente en que trabaja el software sufrirá cambios que significarán demandas de modificación en el propio producto para no caer en la obsolescencia.
Grubb y Takang[27] revisan las definiciones de mantenimiento y de evolución de soft ware, remarcando que muchas de ellas se centran en aspectos específicos mientras que otras son de carácter demasiado general. Las propuestas van desde la visión del mante nimiento como corrección de errores hasta “todo lo que se haga con el software des pués de entregado o lanzado”.
Estos autores diferencian fundamentalmente visiones centradas en la corrección de erro res, la adaptación a nuevos entornos y el soporte al usuario.
Finalmente, adoptan la definición propuesta por la IEEE Std. 1219 mencionada ante riormente.
Kemerer y Slaughter[43] sostienen que las actividades de mantenimiento se realizan en cualquier momento desde la implementación del desarrollo de un producto, en tanto que la evolución del software se define en función del comportamiento dinámico de los sis temas y cómo cambian a lo largo del tiempo.
Bennett y Rajlich[10] adoptan la definición de IEEE 1219 para el mantenimiento, pero utilizan esa expresión para las actividades generales post-lanzamiento, en tanto que evo lución se reserva a una etapa de una fase dentro de un modelo de ciclo de vida en el que el desarrollo pasas por sucesivas secuencias de lanzamientos, evolución y revisión, a partir del lanzamiento inicial.
Cam bios en el software después de la entrega
Los dos términos, mantenimiento y evolución, se refieren a los cambios que se realizan en el software una vez entregado o publicado. Para definir con mayor precisión la incumbencia de cada uno de esos conceptos, conviene revisar las características de las modificaciones en cuestión y las actividades que se relacionan con ellas.
El estándar IEEE 1219[38] propone en la primera fase del proceso de mantenimiento la identificación, clasificación y priorización de las modificaciones o problemas a los que se referirá el mantenimiento. La clasificación se basa en la propuesta de Swanson y Lientz[51], y define los siguientes tipos de mantenimiento:
• correctivo • adaptativo • perfectivo • emergencia
Las tres primeras fueron definidas originalmente por Swanson y Lientz, redefinidas en el estándar que estamos considerando.
En el Glosario Estándar de Terminología de la Ingeniería del Software [37] llama man tenimiento correctivo al que se realiza para corregir fallas; el adaptativo es el que se realiza para volver usable a un programa de computadora en un entorno modificado; el mantenimiento perfectivo, en tanto, es el que se lleva a cabo con el fin de mejorar el funcionamiento, la mantenibilidad u otros atributos del software.
La última categoría no figuraba en la clasificación de Swanson y se refiere a las activi dades de mantenimiento no planificadas y que se realizan para mantener operativo el software. El Glosario Estándar para la Terminología de la Ingeniería de Software
________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
Mantenibilidad y Evolutividad en el Software Líbre y de Código Abierto incluye, en cambio, el tipo de mantenimiento preventivo que se refiere a las tareas que se realizan con miras a evitar futuros problemas.
En gran parte de la literatura sobre mantenimiento y evolución se retoma esta clasifica ción u otras similares basadas en ella; estas tipologías podrían permitir una mirada más precisa sobre las diferentes actividades de mantenimiento, con miras a obtener un cono cimiento más profundo del proceso.
Bennet y Rajlich, en el trabajo citado anteriormente proponen un modelo de ciclo de vida basado en “evidencias empíricas” donde se vincula la evolución y el manteni miento a etapas diferentes de la vida de un software.
La ilustración í muestra el modelo simplificado
Desarrollo inicial
Cambios evolutivos Primera versión en ejecución
evolución
Pérdidá'd'e evoiuiividad Servicio de parches
revision Revisiones, descontinuadas L Retirada paulatina Desáctivsción Cierre
Ilustración I: Ciclo de vida en etapas propuesto por Bennet y Rajlich
1
En ese modelo, los cambios evolutivos responden a nuevos requerimientos y necesida des de adaptar el sistema a nuevos entornos; el servicio de parches se refiere a modifica ciones tácticas para corregir errores o para incorporar pequeñas mejoras.
Similitudes y diferencias entre evolución y mantenimiento
Evolución y mantenimiento de software se usan a veces como sinónimos,a veces con diferencias menores y otras como dos perspectivas diferentes sobre el cambio de los programas informáticos que se realizan posteriormente al lanzamiento o entrega del producto.
Pese a estas similitudes, existen diferencias semánticas que conviene explicitar.
Mens[55] cuestiona las connotaciones negativas del vocablo mantenimiento, que parece sugerir que el software sufre deterioros que deben ser corregidos.
Godfrey[25] retoma la observación de Pamas y otros según la cual el término manteni miento connota mantener en funcionamiento un sistema sin producir modificaciones de diseño.
Jarzabek[39] propone diferenciar mantenimiento de evolución. El primero se refiere a las actividades día a día, en tanto que el segundo término alude a ios cambios a largo plazo.
Cuando discutíamos Jas definiciones, mencionamos la perspectiva de Weiderman y otros respecto de la diferente granularidad a la que se aplican los términos, y el carácter sistèmico y estructural de la evolución. En ei mismo sentido, es interesante recordar la posición de Perry [62], quien advierte que las visiones de la evolución limitadas a las correcciones y mejoras deja de lado aspectos esenciales del trabajo de ingeniería de software, tales como el dominio en el que opera y los procesos que se llevan adelante y que también están involucrados en la evolución
Cook, Ji y Harrison[14] presentan una perspectiva que intenta englobar las diferencias y similitudes entre los dos conceptos, considerando a la evolución como término más general que mantenimiento, pero sin establecer una frontera entre ambos.
Bennet y Rajlich[10] adoptan una perspectiva opuesta a la anterior, reservando el tér mino “mantenimiento” a las modificaciones “tácticas”, es decir, que no comprometen a la arquitectura. Para estos autores, los cambios más generales constituyen la evolución. Esos mismos cambios irían degradando la estructura o comprometiendo la arquitectura,
________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
de modo de tomar cada vez más difícil la evolución hasta limitar los cambios a ajustes menores (mantenimiento), los que también se abandonarán cerca del final de la vida útil del sistema de software.
La falta de uniformidad y consenso en las definiciones dificulta el relevamiento de información sobre estos temas.
Resumiendo, los dos conceptos en cuestión se refieren a las modificaciones en el soft ware, fundamentalmente después del lanzamiento o entrega del mismo; la noción de evolución enfatiza la adaptación a nuevos entornos o requerimientos, en tanto que el mantenimiento destaca la corrección de errores. Por otra parte, el mantenimiento se aso cia frecuentemente a la actividad de corte plazo, con poca incidencia estructural sobre el software y descuidando el contexto en el que opera efectivamente.
A los fines del presente trabajo, resulta relevante conocer los aspectos que diferencian a les dos conceptos para detemiinar la vinculación de los mismos con el objetivo marco, es decir, la posibilidad de reutilizar productos F/OSS.
El desempeño de la comunidad que sostiene un producto F/OSS respecto de la correc ción de errores representa un aspecto a considerar en la eventual selección para el reuso. Por otra parte, la mayor o menor dificultad que represente la modificación del software, tanto para adaptarlo a necesidades particulares como para adicionar nuevas característi cas, constituye un aspecto de gran importancia desde esa misma perspectiva.
Muchos de los productos F/OSS se desarrollan a lo largo de muchos años, sufriendo cambios y modificaciones de diversa profundidad. El contexto, el equipo de desarrollo, la comunidad, los métodos que se siguen y los requerimientos que enfrenta un producto F/OSS a lo largo de su vida útil siguen caminos diferentes a los tradicionales en el mundo empresarial; sin embargo, estos aspectos o dimensiones -en los ténninos de Perry- también intervienen en esa evolución[16]. Las visiones de evolutividad deberán tomar en cuenta estas características.
En definitiva, nos interesa conocer alternativas para evaluar la mantenibilidad y la evo lutividad del software. Las propuestas que analizaremos, no obstante, no siempre se ________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
1.1.2 Definiciones y Dificultades de la Mantenibilidad
Se denomina “mantenibilidad” a la facilidad con que puede modificarse un sistema o un componente de software para corregir fallas, mejorar su funcionamiento o adaptarlo a un nuevo ambiente[3 7].
Esta definición de carácter general no permite establecer cómo evaluar esta caracterís tica, ni qué atributos se vinculan con esta cualidad.
Broy, Dei(3enboeck y Pizka[ 12] hablan sobre los “mitos” acerca de la mantenibilidad. En un estudio realizado en 2003 sobre actividades de mantenimiento en organizaciones de Software de Alemania, observaron que sólo el 20% de los desarrolladores entrevista dos llevaban un control de la mantenibilidad como parte del aseguramiento de la cali dad. Más aún, sobre ese porcentaje que lleva adelante esa verificación, los criterios seguidos son muy diferentes: algunos verifican la orientación a objetos, otros se limitan a valorar la complejidad ciclomática o la cantidad de líneas de código por método, entre otras medidas.
Kajko-Mattson, Lehman[40] y otros elaboraron una serie de sugerencias para la elabo ración de un modelo de mantenibilidad considerando que aún no se dispone de uno que tenga el suficiente consenso y que no se limite a definiciones generales. Esos autores afirman que no existe un modelo de mantenibilidad universalmente aceptado y que eso convierte a la evaluación de la mantenibilidad en un problema cercano a lo imposible; en cambio, la comunidad de software tiende a justificar que cada organización adopte su propia definición de mantenibilidad, en base a la complejidad del concepto; los modelos en uso se orientan a los procesos de software, antes que a los productos.
Entre las objeciones que presentan los autores mencionados, se destaca la insuficiencia del único estándar establecido (el ya mencionado ISO 9126) y la falta de bases comunes que orienten la investigación sobre aspectos de relevancia estratégica, dificultando la creación de modelos y métodos que proporcionen orientaciones para construir, preser var y evaluar la mantenibilidad.
En el trabajo en cuestión, los autores proponen un marco para desarrollar un modelo de mantenibilidad del producto.
________ Mantenibilidad y Evolutividad en el Software Libre ^ d e Código Abierto
1.1.3 Evolución y Evolutividad
El término Mantenimiento, tomado de otras disciplinas ingeníenles, suele percibirse como referido principalmente a la corrección de errores que se realiza a posteriori de la entrega o lanzamiento de un producto de software. Sin embargo, Pigoski señala que muchos estudios concluyen que la mayor parte del esfuerzo de mantenimiento se des tina a actividades no correctivas.
En los años '70. Lehman y otros estudiaron los cambios en los productos de software basándose en la necesidad comprobada de que esos productos sufran modificaciones para seguir siendo útiles a lo largo del tiempo. Hablan, entonces, de evolución del soft w a r e ^ ] .
En los años '70 Lehman analizó los lanzamientos de las diferentes versiones del sistema operativo OS/360. A partir de los datos empíricos de ese estudio, postuló un conjunto de leyes de la evolución del software.
En el año '74 Lehman propuso las 3 primeras leyes; en 1980, incorporó otras dos y en 1996 postuló dos más, completando 8 enunciados[48].
Las leyes de Lehman paiten de una clasificación de los sistemas de software en tres categorías: S, P y E.
Los programas de tipo S son aquellos correctos en sentido matemático, en relación con una especificación formal previa. En el tipo P se clasifican programas que en principio pueden especificarse formalmente, pero donde los usuarios tienen un interés particular en la corrección de los resultados. El tipo E, finalmente, se refiere a aquéllos que meca nizan una actividad social o humana, que modelan e interactúan de alguna manera con el mundo real[52]. Las leyes en cuestión se aplican únicamente a los programas de tipo E, más sujetos a cambios debidos a las demandas de los usuarios.
A continuación presentamos un repaso de las leyes de la evolución del software, a fin de poner de relieve las características de este proceso
Leyes de la Evolución del Software
Ley I: un programa de tipo E que está en utilización debe adaptarse continuamente o de ________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
lo contrario será cada vez menos satisfactorio.
Ley II: La complejidad de los programas se incrementa a medida que evolucionan, a menos que se realice un trabajo específico para mantener la complejidad o reducirla. Ley III: El proceso de evolución de los sistemas tipo E es autorregulado, con las medi das de procesos y productos siguiendo una distribución próxima a la normal.
Ley IY:Conserv&ción de la estabilidad organizacional (tasa de trabajo constante). La tasa promedio de actividad global efectiva en un sistema de tipo E es invariante a lo largo de su vida.
Ley V: Conservación de la familiaridad. Mientras un sistema de tipo E evoluciona, las personas vinculadas con él (por ejemplo, desarrolladores, usuarios, vendedores, etc.J necesitan mantener un dominio sobre su contenido y comportamiento. Un cambio demasiado grande dificultaría el manejo de nuevas versiones del software, por lo que el crecimiento íncremental promedio tiende a mantenerse constante durante la evolución. Ley VI: Crecimiento continuo. La cantidad de funciones que ofrezca un software de tipo E debe aumentar con el tiempo para seguir satisfaciendo a los usuarios
Ley VII: Declinación de la calidad. La calidad del software de tipo E tenderá a decre cer, a menos que sea mantenido y adaptado a nuevos entornos de manera rigurosa.
Ley VIII: Sistema de retroalimentación. El proceso de evolución de los sistemas tipo E constituye sistemas de retroalimentación de nivel múltiple, multi-agente y multi-bucle y deben tratarse como tales para alcanzar mejoras significativas sobre una base razonable.
Evolutividad
En su trabajo mencionado anteriormente, Cook y otros[14] definieron a la evolutividad como la capacidad del software de evolucionar para continuar sintiendo a sus usuarios de una manera económicamente ventajosa.
Esta definición es de carácter muy general, pero permite agrupar diversos estudios rela cionados con la mantenibilidad y la evolutividad en función de la información que ofre cen respecto de la posibilidad de evolucionar de un producto de software.
En definitiva, la búsqueda de producciones científicas referidas a la evolutividad se ________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
relacionan con la facilidad o dificultad que presenta un producto de software para ser modificado con el fin de continuar satisfaciendo la necesidad que le dio origen. Desde el punto de vista evolutivo, las modificaciones en cuestión pueden abarcar aspectos estructurales o arquitectónicos de la aplicación en cuestión.
2 .- M e d ic ió n d e la
m a n te n ib ilid a d y I
e v o lu tiv id a d
2.1 Métricas de Software
”Toda calidad se manifiesta por una cantidad determinada, y sin cantidad no puede-haber calidad" Mao Ze Dong, Métodos de Trabajo de los Comités del Partido. Marzo de 1949
Para evaluar un producto respecto de una característica, necesitamos alguna forma de medirla; tenemos que asignarle algún valor (numérico o no) que nos permita comparar con la misma característica en otros productos.
Fenton y Pfleeger[23] definen a la medición como el proceso por el cual se asignan números o símbolos a atributos o entidades del mundo real, de modo de describirlos siguiendo reglas claramente establecidas.
Diferencian medición de cálculo, explicando que la primera se refiere a la obtención directa del valor de un atributo mientras que el segundo es indirecto y combina diversas mediciones en un ítem cuantificado que reflejan cierto atributo cuyo valor se intenta entender.
En su libro Object Oriented Metrics in Practice, Lanza y Marinescu[47] Adoptan una definición operacional de métricas, entendidas como el mapeo de una característica de una entidad sobre una escala numérica.
El enfoque del libro de Lanza es eminentemente práctico. Advierten que las métricas no son una panacea. Reconocen que es muy difícil la medición del diseño y la calidad del software; no obstante, sostienen que las métricas pueden brindar información impor tante a los ingenieros de software, pudiendo servir como punto de partida para un análi sis más profundo.
Las métricas podrían ayudar como señales que llamen la atención sobre las entidades que presentan valores atípicos de una cierta métrica (excesivamente alto o excesiva mente bajo, por ejemplo).
Para este trabajo, la búsqueda de métricas referidas a la mantenibilidad siguen la línea propuesta por Lanza y Marinescu: no pretendemos dilucidar un conjunto de mediciones definitivas, sino destacar aquellas que pueden aportamos información relevante o
cios valederos sobre las características de un proyecto o un producto de F/OSS.
2.1.2 Medición de la mantenibilidad
El administrador de proyecto de software precisa de elementos que permitan planificar y evaluar la mantenibilidad del software que se desarrolla; por lo tanto, es necesario contar con métricas que den cuenta de este aspecto, o -por lo menos- de un conjunto de atributos que el administrador considere relevantes.
Las mediciones deberían servir para indicamos durante el desarrollo la probabilidad de que nuestro producto de software sea fácil de comprender, mejorar o corregir. Fenton y Pfleeger también advierten que la mantenibilidad no se relaciona sólo con el código; se vincula con la documentación de especificación y de diseño e incluso con el plan de pruebas[23].
Las visiones diferentes respecto de la mantenibilidad implican conjuntos diversos de atributos o factores que inciden en esa características y, por ende, distintos enfoques respecto de qué medir y cómo evaluar esta propiedad.
Estos conjuntos de propiedades y las relaciones entre ellas conforman modelos de man tenibilidad.
________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
2.2 Mantenibilidad y Evolutividad en la bibliografía
general sobre métricas
A continuación, presentamos un repaso de la cobertura de los temías de mantenibilidad y evolutividad como se presenta en la bibliografía general sobre métricas, a fin de tener un marco de referencia que permita comparar y contextualizar las propuestas que revi saremos después.
2.2.1 Mantenibilidad en Fenton y Pfleeger
En el clásico “Software Metrics: a Rigorous and Practical A pproadr’[23], Fenton y Pfleeger comienzan presentando las diferentes categorías de mantenimiento: correctivo, adaptativo, preventivo y perfectivo. Nótese que la última de estas categorías no coincide con las que se exponen con el estándar IEEE 1219-1998 mencionado anteriormente. Sostienen que la mantenibilidad es un atributo externo del software, ya que depende no sólo del producto sino también de los responsables del mantenimiento. Consideran que hay dos grandes enfoques respecto del tema:
1) Enfoque externo: Medición de la efectividad del proceso de mantenimiento. Si el proceso es efectivo, entonces el producto es mantenible
2) Enfoque interno: identificar atributos internos del producto buscando predecir las características del proceso de mantenimiento.
El segundo enfoque es más apropiado para el administrador; sin embargo, los autores advierten la imposibilidad de definir la mantenibilidad exclusivamente en base a los atnbutos internos.
Vista externa de la m antenibilidad
Cualquiera sea la categoría de mantenimiento realizado, los autores proponen la medi ción del Tiempo Medio de Reparación (MTTR, Mean Time To Repair), como el tiempo promedio que lleva al equipo de mantenimiento la implementación de un determinado cambio.
A continuación sugieren las siguientes medidas, dependientes del entorno:
• Proporción del tiempo de implementación del cambio total respecto del número de cambios implementados
• Número de problemas sin resolver
• T iempo gastado en problemas sin resolver
• porcentaje de cambios que introducen nuevos fallos
• número de módulos modificados para implementar un cambio
Este conjunto de medidas constituyen indicadores de aspectos de la actividad de mante nimiento; la selección de los instrumentos adecuados debe ajustarse a las metas y nece sidades de la organización.
A tributos internos que afectan la m antenibilidad
Fenton y Pfleeger enfatizan que la medición de atributos internos puede relacionarse con la mantenibilidad. pero no constituyen una medida de la misma; en todo caso, tales indicadores podrían servir para la evasión de riesgos respecto de la mantenibilidad. Para seleccionar los atributos internos según su incidencia en la mantenibilidad, es necesario vmcularlos a la evaluación externa.
Medidas simples, como la complejidad ciclomática, resultan insuficientes como indica dores de mantenibilidad, ya que capturan una visión muy limitada de la estructura del software.
Una serie de medidas que permitiría detectar problemas estructurales qüe se relacionan con la mantenibilidad es la familia VINAP, propuesta por Bache. Las mismas preservan los axiomas que él mismo postula para caracterizar la complejidad del flujo de control. Fenton y Pfleeger afirman que estudios empíricos sostienen que VINAP es un indicador de mantenibilidad más confiable que otras métricas de complejidad.
2.2.2
Kan: Métricas del proceso de mantenimiento
En su libro “Metrics and Models m Software Quality Engineering,,[41], Stephen Kan incluye un apartado sobre métricas de mantenimiento de software en su capítulo cuarto (Software Quality OverView).
________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
El autor considera la fase de mantenimiento, entendida como una instancia posterior a la entrega del producto. En ese marco, las métricas no apuntan tanto a la calidad del producto sino más bien a la calidad del proceso de mantenimiento.
El proceso de mantenimiento será mejor cuanto antes y mejor sea la corrección de fallas desde el momento en que las mismas se detectan. De allí surgen medidas básicas, como la duración promedio del intervalo entre el informes de error y el tiempo promedio que demoran en cerrarse.
________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
Una lista de errores pendientes al final de cada mes brinda información significativa respecto del proceso de mantenimiento.
Una métrica que recoge esta información es el BMI (Backlog Management Index), defi nido de la siguiente manera:
_ problemas cerrados en el mes problemas llegados en el mes *100
Tiempo de respuesta de corrección y reactividad de corrección
Un indicador de la eficiencia del proceso de mantenimiento estará dado por ei tiempo promedio que transcurre entre la comunicación de una falla y el momento en que se corrige.
En general, resulta más útil diferenciar las fallas por su gravedad, de modo que la orga nización encargada del desarrollo evalúe con mayor rigor la corrección de los defectos que pueden traer consecuencias más severas en el desempeño del software.
Es posible que las duraciones de los intervalos mencionados sean muy variables, por lo que podría ser más adecuado utilizar como medida a la mediana antes que a la media.
Porcentaje de correcciones dem oradas
La métrica “promedio (o mediana) del tiempo de respuesta'’ es una medida de tendencia central; una medida más sensible es el porcentaje de correcciones demoradas:
j _ núm de correcciones cuyo tiempo excedido según su gravedad F núm de correcciones producidos en el tiempo especificado
C alidad de corrección
La calidad de corrección o la cantidad de correcciones defectuosas constituye otra métrica de importancia respecto del proceso de mantenimiento. Una corrección es defectuosa si no resuelve el problema informado o genera nuevos problemas o errores.
Efectividad de la remoción de defectos
En el capítulo 6, Kan[41] retoma el tema de la efectividad en la remoción de defectos. Realiza una revisión de la literatura.
En los 60 el desarrollo consistía básicamente en codificación y prueba, siendo la prueba de software la única actividad de remoción.
En los 70 adquirieron importancia la inspección y la revisión formal como maneras de favorecer la calidad del producto de software. Kan retoma [21] el trabajo de Fagan sobre inspección de software, de donde surge la noción de eficiencia de detección:
.. . • j j .. errores encontrados en la inspección eficiencia de detección= ---- —--- t---x 100
total de errores antes de la inspección
Pese a su importancia, esta medida no fue muy discutida hasta mediados ele los '80, cuando Casper Jones propone la siguiente definición:
~ . . , ., defectos encontrados . nr.
eficiencia de remocion=-—---1— --- —--- ;— x 100
defectos encontrados+ defectos no encontrados
Se entiende por “defectos no encontrados” a los que se detectan con posterioridad al proceso analizado.
Kan también presenta las medidas propuestas por Kolkhorst y Macina[46], y que fueran elaboradas en el ámbito de los procesos de calidad definidos por IBM Houston en sus desarrollos para la NASA en los años '80:
. , , .. núm de errores mayores de inspección
Porcentaje de detección temprana= --- ;---—--- x 100
num total de errores
Los errores mayores de inspección se refieren a los errores encontrados por la inspec ción de código y de diseño que podrían resultar en un Informe de Discrepancia válido (DR, Discrepancy Report) en caso de que esos errores se incorporen al software. Estos ________ Mantenibilidad y Evolutividad en el Software Librea de Código Abierto
Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto informes de discrepancia registran una diferencia entre el software y la letra, los objeti vos o los propósitos operativos expresados en la especificación de requerimientos.
El número total de errores es la suma de los errores mayores de inspección y los infor mes de discrepancia válidos.
En 1987 H. R. Dunn propuso una medida de eficiencia de remoción un poco diferente:
E= N
N + S *100
Aquí E es la efectividad de una actividad, N el número de fallas detectados por la acti vidad y S las fallas encontradas con posterioridad. Esta métrica puede ajustarse limi tando los errores considerados a aquéllos que estaban presentes durante el desarrollo de la actividad evaluada y que fueran susceptibles de evidenciarse mediante la actividad en cuestión.
En 1992 Daskalantonakis[15] presentó las métricas usadas por Motorola, entre las cua les figura la Efectividad Total de Contención de Defectos (TDCE) y la Efectividad de Contención de la Fase (PCEi)
N° de defectos antes del lanzamiento
IDCE = ----
---N°de def. prelanzamiento + N°de def. postlanzamiento
____________n° de errores de la fase i__________ ' n° de errores de la fase i + n°de defectos de ia fase i
Kan observa que las métricas relevadas son muy similares, pudiendo llevar a confusio nes; tales confusiones serían insignificantes cuando se trate de mediciones referidas al proceso global de remoción de defectos o a aiguna fase específica puntual. Sin embargo, durante el desarrollo los defectos “posteriores” a la etapa aún no se manifesta ron.
La efectividad en ia rem oción de defectos vista de cerca
En las métricas relevadas hasta aquí no se consideró que no sólo se producen al comienzo del desarrollo sino que cada etapa puede incorporal- nuevos errores.
senta en la Ilustración II.
La eficiencia de la remoción para una etapa se definiría de la siguiente manera:
j-, errores correqidos
t ---- ---;---2—---x loo
errores al comienzo de la fase + errores introducidos durante la fase
Si se considera muy bajo el porcentaje de errores corregidos incorrectamente, el cóm puto de la eficiencia puede limitarse a los defectos detectados.
________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
Kan propone componer una matriz de defectos donde se deje constancia de la etapa en la que se encontró el error. De esta forma, se puede determinar la efectividad correspon diente a cada fase de acuerdo con la fórmula que figura más arriba.
2.2.3 Tian: Prevención de defectos y mejora de procesos
Jeff Tian incluye un capítulo referido a la prevención de defectos y mejora de procesos en su libro “Software Quality Engineering. Testing, Quality Assurance and quantifiable Impío vement’ ’[83].
Tian diferencia la prevención de defectos de otras actividades de aseguramiento de la calidad, las cuales tratan con defectos que están presentes una vez concluido el desarro llo.
Existen dos problemas en los enfoques de QA (Aseguramiento de la Calidad) en el soft ware:
• la corrección de errores ya inyectados (incorporados al desarrollo) es enorme mente costosa
• la ineficacia y las limitaciones de las técnicas de QA actuales para detectar erro res en etapas tempranas.
Se pueden automatizar algunas actividades propensas a introducir errores; ese enfoque se denomina “bloqueo de errores”
Por otra parte, pueden analizarse las causas por las que se introducen actividades inco rrectas; ese enfoque se denomina “remoción de fuentes de error”.
Ambos enfoques integran las técnicas de prevención de efectos.
A nálisis de las causas raíz para la prevención de defectos
Al comienzo del desarrollo no se dispone de datos respecto de las fallas del software a desarrollar; por lo tanto, es necesario basarse en la experiencia previa, especialmente la que se refiere a productos o procesos similares a los que se prevé llevar adelante.
El análisis de causas puede realizarse de dos formas:
• Análisis lógico: se busca establecer las relaciones causales que vinculan errores y defectos. Esta aproximación exige especialistas con amplios conocimientos sobre los procesos de desarrollo, el dominio del sistema en cuestión, y el entorno general.
• Análisis estadístico: intenta establecer relaciones predictivas mediante correla ciones estadísticas en desarrollos previos.
A partir de la identificación de las causas, se pueden definir actividades de bloqueo de errores o remoción de fuentes de error.
Clasificación y análisis de errores Tipos generales de análisis de defectos
Cuando se descubre un defecto en particular, se pueden realizar análisis individuales referidos a ese defecto; a medida de que se dispone de registros más amplios -una mayor cantidad de registros-, también pueden plantearse análisis de carácter más gene ral.
En ambos casos, las preguntas que orientan el análisis son similares, por ejemplo: • ¿Qué?: de qué se trata el defecto, en qué categorías podría incluirse
• ¿Dónde?: a fin de brindar información de retroalimentación mediante el análisis de la distribución de los defectos
• ¿Cuándo?: en qué fase o etapa del desarrollo se detectó o se produjo el error • ¿Antes o después del lanzamiento?: es una extensión de la pregunta anterior,
aunque de carácter más general.
• ¿Cómo y por qué?: determinar de qué manera se introdujo el defecto y por qué causas.
Análisis de distribución de defectos
Este tipo de análisis buscar responder el “qué” el “dónde” de las preguntas anteriores. Por lo general, estos análisis se centran en la corrección de defectos (encontrados durante la revisión de cualquiera de las instancias del desarrollo) y en las fallas que aún estén pendientes de resolución.
Los datos relevados pueden llamara la atención sobre módulos o procesos, para los cua les se podrán definir criterios y métricas con miras a su mejora en el futuro.
El análisis de tipo de defectos se relaciona con categorías que pueden implicar diferen tes consecuencias o distintas relevancias. Tian presenta ejemplos de IBM, donde los defectos se vinculan con atributos de calidad (como capacidad, usabilidad, performance, confiabilidad, etc.), así como la clasificación de errores reflejados en el log de un servi dor Web referidos a un sitio en particular.
Una vez detectados los defectos, se puede analizar la ubicación de los mismos. Tian ejemplifica con un estudio de IBM que pone de relieve qué módulos presentan mayor cantidad de defectos corregidos
Observaciones generales
Los análisis presentados más arriba no permiten adoptar medidas tempranas para evitar defectos. Se necesitan medios para identificar áreas potencialmente riesgosas o de alta cantidad de defectos, a partir de los datos históricos.
________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
Análisis de tendencias de defectos y modelos dinámicos de defectos
Los datos referidos a los defectos incluyen habitualmente información temporal; como mínimo, los defectos que se encuentran se clasificarán como previos o posteriores al lanzamiento del producto. Es muy probable que la información refiera la fase del desa rrollo en la que se produjeron los defectos.
A partir de esa información pueden esbozarse modelos tendientes a brindar prediccio nes.
Tian muestra la elaboración de una matriz donde se cuantifican los defectos para cada fase del desarrollo;
Tenemos hasta aquí un panorama de la diversidad y heterogeneidad con que se aborda la medición de la mantenibilidad y la evolutividad en la bibliografía general sobre métricas, y diferentes visiones acerca de los factores que influyen y los atributos que componen estas características.
Podemos ver que hay un consenso bastante extendido sobre la relevancia de ciertos aspectos en cuanto a su incidencia en la mantenibilidad y evolutividad; no obstante, los conceptos en juego no siempre se entienden de la misma manera.
En la siguiente sección repasaremos los resultados de diversos estudios empíricos, tomando en cuenta los métodos utilizados y remarcando eventuales fortalezas y/o debi lidades de cada trabajo.
2.3 Modelos de mantenibilidad y de Evolutividad
No existe un consenso general respecto de cómo evaluar la mantenibilidad de un pro ducto de software; sin embargo, se han producido una gran cantidad de trabajos referi dos a las características que inciden en que un software sea fácil o difícil de mantener. nn el trabajo ya mencionado de Kajko-Mattson y otros[40] se hace hincapié en la nece sidad de establecer bases que permitan evaluar los productos y no sólo los procesos, como proponen los estándares actuales (CMMI, ISO 9001 y Spice).
Los autores proponen crear un modelo de mantenibilidad del software (SMM por sus siglas en inglés), para lo cual postulan un conjunto de pautas generales para desarro llarlo. El modelo que plantean se orienta a evaluar la mantenibilidad en función del pro ducto.
Entre los aspectos que debería considerar el modelo se destacan:
• Características comunes: se trata de definir y validar aspectos que inciden en la mantenibilidad en cualquier sistema de software
• Características variables: pueden variar según los tipos de software. Ejemplifi can con el atributo “comprensibilidad” (understandability), que puede incluir factores descriptivos, de modularidad y estructurales que deberían considerarse bajo diferentes metodologías.
• Características cualitativas y cuantitativas: Es necesario definir modelos cualita tivos y cuantitativos para evaluar diferentes características
• Características de rastreabilidad: la posibilidad de evolución de un artefacto depende fuertemente de la posibilidad de vincularlo con artefactos anteriores y posteriores, desde los niveles más bajos a los más altos.
• Niveles de madurez. Las características de mantenibilidad deberían asignarse a niveles diferentes de madurez, que reflejen la confiabilidad de que un producto de software satisfaga ciertas pautas de mantenibilidad.
• Taxonomía de defectos de mantenibilidad.
________ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
• Ejemplos de sistemas de software mantenibles y no mantenibles, que puedan proporcionarse para compararlos con sistemas de software específicos.
Pizka y Deipenbóck[63], en cambio, sostienen que la mantenibilidad es una caracterís tica compleja que no se limita a las características del producto de software; por el con trario, consideran tres dimensiones de la mantenibilidad, compuestas por las propieda des técnicas del sistema en consideración, las habilidades de la organización que se encarga de la tarea y las características de la ingeniería de requerimientos. Para los fines del presente trabajo, resulta de mayor interés la incidencia de las propiedades técnicas del sistema.
Hashim y Key[31] se basan en los procesos que involucra la fase de mantenimiento, a partir de la diferenciación entre los tipos de mantenimiento correctivo, perfectivo y adaptativo. Sostienen, entonces, que la mantenibilidad puede verse como dos cualidades separadas: evolutividad y reparabilidad.
La reparabilidad se refiere al mantenimiento correctivo. Los autores definen a un sis tema como ‘'reparable1' si permite la remoción de los defectos residuales presentes luego del lanzamiento o entrega del software, así como los errores que se introdujeran durante el propio mantenimiento.
Los autores consideran que la modularidad del sistema constituye un factor principal en la reparabilidad, permitiendo acotar la incidencia de los defectos a un conjunto reducido de módulos.
Respecto de la evolutividad, los autores advierten que la modularidad favorece la intro ducción de modificaciones asociadas con la evolución del software; sin embargo, las propias modificaciones pueden afectar negativamente la modularización original.
La evolutividad se relaciona con el mantenimiento perfectivo y el adaptativo.
Hashim y Key[31] citan el trabajo de Briand y otros donde identifican los siguientes factores que afectan a la mantenibilidad:
• Falta de rastreabilidad • Falta de documentación
Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto • Mal diseño e implementación
• Lenguaje de programación, herramientas y técnicas de desarrollo inapropiados. Los autores proponen un modelo de atributos de la mantenibilidad del software de acuerdo con el cuadro que aparece a continuación.
; j Modularidad
, Legibilidad
Lenguaje de programación í
i Modelo de Atributos de Mantenibilidad Estandarización
Nivel de validación y prueba
¡Complejidad |
Rastreabilidad ¡
Kemerer y Slaughter[44], basándose en observaciones empíricas y en la literatura, sos tienen que hay una serie de factores asociados con la cantidad y el tipo de manteni miento que se realiza sobre determinados módulos. En particular, destacan tres:
• Funcionalidad
• Prácticas de desarrollo • Complejidad del software
La funcionalidad de una aplicación puede determinar diferentes necesidades y frecuen cias en su modificación. Los autores observan que los módulos de software en un sis tema estratégico deben mejorarse con mayor frecuencia que otro dedicado principal mente a la gestión contable.
Respecto de las prácticas de desarrollo, sostienen que determinadas técnicas (por ejem plo, los generadores de código) producen aplicaciones menos propensas a errores.
La complejidad para estos autores se refiere a características del software que lo vuel ven más difícil de entender y modificar. Sostienen que existen varias dimensiones de la complejidad (citando a Banker y otros[5]), pero se concentran en lo que denominan
densidad de decisión o complejidad ciclomática.
La densidad de decisión, entendida como la cantidad de decisiones o caminos de control por línea de código, es un factor que se asocia reiteradamente con la complejidad, entendiendo que una mayor cantidad de rutas de ejecución obscurece la relación entre entradas y salidas y dificulta la comprensión del código por parte de los programadores. David Peercy[61] presentó en 1981 un modelo con 6 factores que favorecen la manteni- bilidad: • modularidad • descriptividad • consistencia • simplicidad • expandibilidad • instrumentación
La modularidad se refiere al particionamiento lógico de la aplicación y a la relativa independencia de sus partes. La descriptividad se refiere a la disponibilidad de descrip ciones del diseño del sistema y su documentación. La consistencia se refiere al cumpli miento de reglas de denominación (nombres de variables, de métodos, de módulos, por ejemplo), preferiblemente de acuerdo con convenciones y estándares referidos a los artefactos en cuestión.
La simplicidad es un atributo opuesto a la complejidad; toma en cuenta aspectos tales como el lenguaje de programación (Peercy lo ejemplifica indicando que un programa escrito en un lenguaje de alto nivel es más sencillo de entender que uno escrito en Assembler) así como la cantidad de operandos, operadores , estructuras de control ani dadas, etc.
La expandibilidad se refiere a las características que facilitan el escalamiento de la apli cación (incorporación de nuevas prestaciones, por ejemplo). La instrumentación designa la inclusión de herramientas y técnicas de prueba integradas en el desarrollo.
En esta muestra observamos que no hay consenso respecto de los atributos de la mante- ________ MantenibiISdad y Evolutividad en el Software Libre y de Código Abierto
Mantenibilidad y Evoiutividad en el Software Libre y de Código Abierto puestas presentadas más arriba y a los enfoque más frecuentes en el ámbito de la inves tigación sobre el tema, revela que algunos factores cuentan con gran aceptación tanto en ámbitos académicos como industriales.
Stavrinoudis y otros[81], en tanto, apelaron al modelo de Factores-Criterios-Métricas de McCall, considerando que los factores a tener en cuenta en la mantenibilidad son la consistencia, simplicidad, concisión, autodescriptividad y modularidad.
Hordijk y Wieringa[34] plantearon el estudio de la mantenibilidad de productos de soft ware tomando los cambios como indicadores del atributo en cuestión. En base a esa consideración y a la literatura revisada por los autores, proponen la siguiente clasifica ción de factores:
• Factores del producto de software:
• Nivel de especificación, donde consideran la corrección o el tamaño funcio nal.
• Nivel de diseño, donde incluyen la modularidad y el acoplamiento.
• Nivel de código, como el tamaño del código, la complejidad, la madurez o la duplicación
• Factores del proceso de mantenimiento • Frecuencia de los cambios
• Procedimientos de mantenimiento • Procedimientos de prueba del software • Propiedades de recursos
• Propiedades del equipo de desarrollo, tales como tasa de actividad, estruc tura de comunicación, rotación del personal
• Propiedades de los miembros del equipo, tales como las habilidades y el conocimiento del sistema
• Infraestructura de mantenimiento, entre los que se considera el entorno de desarrollo y las herramientas.
• Propiedades del cambio
• Propiedades funcionales del cambio, como el tamaño funcional, los tipos de cambio, o la complejidad funcional.
• Propiedades de la implementación del cambio, entre los que se incluyen el tamaño del cambio, el alcance del cambio o el potencial del fallo.
El trabajo en cuestión se orienta a indagar qué decisiones de diseño tienen influencia sobre el esfuerzo de mantenimiento. La mantenibilidad a la que apuntan se refiere al esfuerzo que requiere el cambio funcional.
Riaz, Mendes y Tempero[69] presentaron en 2009 una revisión sistemática sobre métri cas y predicción de la mantenibilidad. Allí observaron que los aspectos que con más frecuencia intentan relacionarse con la mantenibilidad fueron la complejidad, el tamaño y el acoplamiento, fundamentalmente relevados a nivel de código.
La clasificación que proponen Hordijk y Wieringa[34] permite organizar los factores a tomar en cuenta en la evaluación de la mantenibilidad de un producto de software. Si bien los factores y los atributos asociados en las perspectivas presentadas son diferentes, hay aspectos que se repiten con frecuencia.
Esta heterogeneidad permite comprender la cantidad de estudios que intentan establecer relaciones entre la mantenibilidad o la evolutividad y diferentes características del soft ware o de los procesos de desarrollo. Estos últimos se definen como variables indepen dientes, en tanto que se analizan las posibles correlaciones entre los datos obtenidos mediante diferentes métodos (correlación lineal, multilineal, árboles de regresión, etc.) para ofrecer una confiabilidad empírica en las relaciones sugeridas.
A la hora de plantearse estudios empíricos, resulta relevante también la definición de mantenibilidad que se adopta y los indicadores que se consideran para evaluar las varia ciones en este atributo.
La complejidad aparece como un factor relacionado con la mantenibilidad, si bien no se explicitan con claridad la manera en que ese aspecto influye. En la próxima sección repasamos definiciones y propuestas de evaluación de esta característica.
Mantenibilidad y Evolutividad en el Software Librea de Código Abierto
2.4 La Complejidad del Software
A fines de los '80 Elaine Weyuker escribió un trabajo[85] que tuvo gran influencia en la investigación en las áreas de métricas y mantenimiento de software.
Weyuker se propuso formalizar las características que debería cumplir una medida de la complejidad del software. Para ello, consideró que los programas están constituidos por programas más pequeños, los que a su vez se integran con asignaciones y predicados. Una asignación constituye un “cuerpo de programa”, y los cuerpos de programa pueden ser condicionales (se ejecutan según un predicado) o compuestos (integrado por otros cuerpos de programa).
Parte de la perspectiva de que una declaración de programa tiene la forma P(variables) -es decir, es una función de las variables de entrada- y una declaración de salida tiene la forma S(Variables).
De acuerdo con esas definiciones, un programa consta de una declaración de programa, un cueipo de programa y una declaración de salida.
La complejidad de un cuerpo de programa P se expresaría mediante un valor numérico | P| no negativo con las siguientes características:
V P , Q | P | < | Q ¡ v | Q K | P |
Las propiedades que debería cumplir una métrica que represente la complejidad son las siguientes:
1) No todos los programas pueden tener la misma complejidad
(3P)PQ)(|PM Q|)
2) Dado un número no negativo c, existe una cantidad finita de programas cuya complejidad es igual a c.
3) Existen programas diferentes P y Q para los cuales el valor de la complejidad es el mismo
4) Dos programas que realizan la misma función pueden tener valores de
dad diferentes (la complejidad no está dada por la función del programa)
{ 3P) ( 3Q) { P = Qa\P\^\Q\)
5) La composición de dos programas tendrá un valor de complejidad igual o mayor a cada uno de los programas integrantes
( V P ) ( V Q ) ( | P | ^ | P ; Q ¡ )a(|Q|^|P;Q!)
6) La composición de programas deben poder arrojar complejidades, aún cuando los programas por separado presentan igual valor de complejidad.
3 P , 3 Q , 3 R / ( \ P \ = \Q\)a(\P;R\*\ Q;R\)
7) El valor de la complejidad debe ser sensible al orden en el que se encuentran las sentencias en un programa. Podría haber dos programas integrados por las mis mas instrucciones dispuestas en órdenes diferentes y -como consecuencia- devolver valores diferentes de complejidad.
8) Si P es el programa Q renombrado, |P|=|Q|
9) La complejidad para la composición de dos programas debe poder ser mayor que la suma de las complejidades por separado.
______ Mantenibilidad y Evolutividad en el Software Libre y de Código Abierto
A partir de esta serie de características, Weyuker observa que ni la complejidad ciclo- mática, ni la medición de esfuerzo (derivada del Volumen de Halstead), ni la compleji dad del flujo de datos constituyen métricas que reflejen apropiadamente la complejidad de un programa.
En el año 1986 Keamey y otros publicaron un artículo[42] que tuvo amplio impacto respecto del concepto y medición de la mantenibilidad.
Los autores plantearon la falta de consenso en cuanto a la definición de qué se entiende por complejidad y objetaron la falta de una teoría que modele los programas, los pro gramadores, el entorno de programación y las actividades de programación. Citan la definición de Basili, que entiende a la complejidad como la medida de los recursos gas tados por el sistema en la interacción con una porción de software para realizar una
