Ingeniería de Software Basada en Búsqueda

En la ingeniería de software (IS), como en cualquier otra disciplina de la ingeniería, surgen de forma natural problemas de optimización, previamente, durante y después del desarrollo de software. En estos problemas intentamos encontrar los mejores valores para las variables que intervienen en ellos.

Existen métodos que pueden resolver problemas de optimización pequeños de forma exacta, sin embargo, para problemas reales, cuyo tamaño es generalmente grande, el tiempo de ejecución de estos métodos se incrementa de forma considerable. Esta es la razón principal por la cual este tipo de problemas se resuelven mediante métodos heurísticos, los cuales, a pesar de no ofrecer una garantía de desempeño, usualmente encuentran soluciones buenas y prácticas. Precisamente, la ingeniería de software basada en búsqueda (ISBB) utiliza heurísticas para resolver los problemas que aparecen en la IS.

El objetivo de este artículo no es explicar cómo funcionan las heurísticas ni cómo se resuelven estos problemas, sino plantear algunos problemas de la IS como problemas de optimización y presentar un panorama de la aplicación de la ISBB.

La IS como problemas de optimización

Un problema de optimización considera una o más variables de decisión, cuyos valores definen el espacio de búsqueda. Este espacio se explora con el fin de encontrar aquellos valores que ofrecen la mejor evaluación de la o las funciones objetivo que queremos minimizar o maximizar. Estas funciones objetivo comúnmente están en conflicto, es decir, la optimización de una de ellas implica la degradación de las otras. A continuación expondré tres problemas comunes en la IS y describiré las variables, el espacio de búsqueda y las funciones objetivo a optimizar.

Problema de la siguiente versión

Idealmente, la siguiente versión de un producto debería considerar todos los requisitos de todos los clientes que han dado retroalimentación sobre la versión actual, esto con el fin de mantener a los clientes y, sobre todo, que estén satisfechos. Sin embargo, no siempre se pueden tomar en cuenta la totalidad de los requisitos, muchas veces por cuestiones de costo. En este caso surge la siguiente pregunta: ¿cuál es el subconjunto de requisitos que equilibra el costo de desarrollo de software y la satisfacción de los clientes? En este problema, la variable de decisión es un subconjunto de requisitos y tenemos que considerar todos los posibles subconjuntos. Por ejemplo, si la cantidad de requisitos es 50, el número de subconjuntos posibles de requisitos, es decir, de soluciones potenciales, es 2⁵⁰, que son aproximadamente 10¹⁵. Considerar todos estos subconjuntos para encontrar aquél que ofrece la mejor evaluación de los objetivos es prácticamente imposible.

Las funciones objetivo en este problema son: el costo de desarrollo de software, que se tiene que minimizar, y la satisfacción de los clientes, que se tiene que maximizar. Obviamente, si queremos que los clientes estén ampliamente satisfechos, deberíamos considerar, si no la totalidad de los requisitos, un subconjunto muy grande de éstos y, consecuentemente, esto implicaría un mayor costo de desarrollo. Por el contrario, si queremos que el costo de desarrollo sea mínimo, deberíamos considerar un subconjunto pequeño de requisitos, lo cual reduciría considerablemente la satisfacción de los clientes.

Problema de las pruebas de software

Los sistemas reales generalmente son grandes y con cualquier cantidad de opciones y ramificaciones. Probar este tipo de sistemas de forma exhaustiva no es práctico, por lo que se deben definir casos de prueba. Aquí aparece la pregunta ¿cuál es el conjunto más pequeño de casos de prueba que abarca todas las ramas del sistema? La variable que interviene en este problema es un subconjunto de casos de prueba y el número de soluciones potenciales es similar al del problema de la siguiente versión.

Las funciones objetivo en este problema son: la confiabilidad del sistema, que se debe maximizar, y el costo de probar el sistema, que se debe minimizar. Claramente, si queremos reducir el costo de la etapa de pruebas, el número de casos de prueba será reducido, consecuentemente la confiabilidad del sistema será baja o nula. Por el contrario, si queremos garantizar un producto confiable, se tendrá que invertir mucho en salarios de ingenieros de pruebas.

Problema de la planificación de un proyecto de software

Generalmente, cada uno de los ingenieros de software que pueden participar en un proyecto de desarrollo conoce sólo algunas de las tecnologías necesarias para llevar a cabo el proyecto. De acuerdo a sus conocimientos, una ingeniera de software comúnmente se clasifica como principiante, avanzada o experta y su sueldo depende de su categoría y su experiencia. Por otro lado, un proyecto de desarrollo de software se puede dividir en tareas y el inicio de cada una de éstas podría depender de la terminación de algunas otras. Cada tarea tiene un esfuerzo estimado y se necesitan ingenieros de software con ciertas habilidades y conocimientos de ciertas tecnologías para que pueda concluirse. Este problema consiste en asignar ingenieros de software a cada una de las tareas del proyecto, de tal forma que el costo del mismo sea mínimo y la fecha de entrega sea lo más cercana a la fecha comprometida.

Las variables involucradas en este problema son binarias y cada una corresponde a si una ingeniera de software es asignada o no a una tarea del proyecto. Entonces, el número de variables es igual al producto del número de ingenieros de software por el número de tareas. Como ejemplo, podemos considerar que 10 ingenieros de software van a participar en un proyecto se podría dividir en 10 tareas. Por lo tanto, estamos hablando de 100 variables binarias y la cantidad de soluciones potenciales es 2¹⁰⁰, que son alrededor de 10³⁰. Obviamente no podemos probar cada una de estas diferentes asignaciones para encontrar aquella que minimiza el costo.

Este problema se puede complicar aún más. Por ejemplo, ¿qué pasa cuando una de las ingenieras deja de participar en el proyecto? En este caso, tenemos que encontrar una nueva asignación que provoque el menor cambio en la asignación actual, de tal forma que el incremento en el costo sea mínimo y la fecha de entrega se desplace lo menos posible.

Aplicación de la ISBB

La ISBB se propuso formalmente hace poco más de una década, aunque ya para entonces existían algunos estudios que aplicaban heurísticas, principalmente a las pruebas de software. De acuerdo con el Repositorio de la ISBB [1], ésta se ha aplicado a una variedad de problemas de la IS. Para tener una perspectiva de las aplicaciones, la Figura 1 muestra una gráfica de la proporción de artículos publicados por área de conocimiento de la IS.

Fig 1. Proporción de artículos de la ISBB publicados por área de conocimiento de la IS.

Como en muchas otras áreas de investigación, la gran mayoría de estas publicaciones son puramente académicas, sin embargo, el interés por aplicar la ISBB en la industria del software se ha incrementado en los últimos años. Un estudio reciente [2] destaca los siguientes casos de éxito. En Chrysler, una de las primeras empresas en utilizar la ISBB, experimentaron con estas técnicas para las pruebas funcionales de un sistema de estacionamiento y para las pruebas temporales de los controladores de las bolsas de aire. Microsoft utilizó la ISBB para la incorporación de cálculos de punto flotante en PeX, su herramienta de pruebas de software. Google integró la ISBB para la optimización de pruebas de regresión en su proceso de pruebas. La NASA, Motorola y Ericsson han hecho experimentos con la ISBB para el análisis y la optimización de requisitos.

Además, se han identificado áreas potenciales para la aplicación de la ISBB [3], tales como la optimización de los objetivos en conflicto en los paradigmas ágiles, en los sistemas basados en cómputo en la nube y en los sistemas móviles y embebidos.

Conclusiones

Los problemas que surgen en la IS pueden ser tratados, como los de cualquier otra disciplina de la ingeniería, como problemas de optimización. Estos problemas consideran muchas variables y generalmente el número de soluciones potenciales es muy grande. Consecuentemente, no es posible utilizar métodos exactos para resolverlos, sino métodos heurísticos que aunque no garantizan la mejor solución, ofrecen soluciones buenas y prácticas. Con sus pocos 10 años, la ISBB es una área potencial de investigación aplicada que utiliza heurísticas para resolver los problemas de optimización que aparecen en la IS. La industria del software ha aplicado ISBB a algunos de estos problemas con logros significativos y se han detectado áreas prometedoras para su utilización.

Referencias

[1] Y. Zhang, M. Harman, A. Mansouri. The SBSE repository: A repository and analysis of authors and research articles on Search Based Software Engineering. CREST Centre, UCL. http://crestweb.cs.ucl.ac.uk/resources/sbse_repository

[2] M. Harman, A. Mansouri, Y. Zhang. Search-based software engineering: Trends, techniques and applications. ACM Computing Surveys, 45(1), 11.

[3] M. Harman. Software engineering meets evolutionary computation. Computer, 44(10), 31-39.