Administración de Conocimiento como soporte al Mantenimiento de Software

Transcripción

1 Administración de Conocimiento como soporte al Mantenimiento de Software Oscar M. Rodríguez 1, Ana I. Martínez 1, Jesús Favela 1, Aurora Vizcaíno 2 1 CICESE, Departamento de Ciencias de la Computación, México. orodrigu@cicese.mx, martinea@cicese.mx, favela@cicese.mx 2 Universidad de Castilla-La Mancha, Departamento de Informática, España. aurora.vizcaino@uclm.es Resumen. En muchas organizaciones de desarrollo de software, el principal capital es el conocimiento de sus miembros. Debido a esto, es necesario que cuenten con mecanismos que les permitan hacer un uso eficiente del mismo, evitando su pérdida y desaprovechamiento. En particular, el mantenimiento del software (MS) es una actividad donde existen problemas relacionados con estos dos aspectos. La administración de conocimiento (AC) aporta mecanismos que pueden ser una solución a este tipo de problemas. Este artículo presenta una propuesta para utilizar la AC como apoyo en la solución de los problemas asociados al MS. Palabras clave. Administración de conocimiento, mantenimiento de software, agentes. 1 Introducción La ingeniería de software es una práctica que hace uso intensivo del conocimiento [2], por lo que las organizaciones de desarrollo de software han tomado un interés especial en la administración del mismo [3]. Aun cuando no existe una definición generalizada sobre su significado [13], la Administración del Conocimiento (AC) puede entenderse como un conjunto de esfuerzos que buscan el mejor aprovechamiento del conocimiento dentro de las organizaciones. Dentro de la ingeniería de software, estos esfuerzos se han orientado, principalmente, al aprovechamiento y reutilización de experiencias o lecciones aprendidas, con el fin de repetir casos exitosos o evitar cometer los mismos errores [10]. El mantenimiento es la etapa de la ingeniería del software que se encarga de mantenerlo en funcionamiento una vez que éste ha sido liberado [6]. Si consideramos que un sistema puede durar en funcionamiento por décadas [4], puede entenderse que algunos autores concuerdan en que es la etapa del ciclo de vida del software que consume la mayor parte del costo y recursos del mismo (ej. [5]). Sin embargo, con frecuencia no se da al mantenimiento la importancia que tiene [4]. Esto ha llevado a que el interés en la solución de problemas en el desarrollo de software, por lo general se oriente a apoyar las etapas de administración, análisis, diseño y desarrollo de nuevos proyectos, no así al mantenimiento de los existentes. Durante los largos períodos de vida de los sistemas de software, el conocimiento obtenido con la experiencia de los desarrolladores y quienes han tenido la Presentado en el Taller de Ingeniería del Software del ENC 2003, Tlaxcala, México, 8-9 Septiembre, Publicado En: Sossa Azuela, Juan Humberto y Pérez Cortés, Elizabeth, (Eds.), Avances en Ciencias de la Computación: Memorias de los talleres del ENC 2003, p

2 responsabilidad de mantenerlos en funcionamiento, se pierde una vez que estos dejan la empresa o son asignados a otros proyectos [3]. Si consideramos que con frecuencia es personal sin experiencia el asignado a las nuevas tareas de Mantenimiento de Software (MS) [4], tenemos como consecuencia la falta de suficiente experiencia para llevarlo a cabo de la mejor manera. Si a esto agregamos la falta de documentación que por lo general existe en los grupos de mantenimiento [7], el resultado es la necesidad de reentrenarlos desde un inicio, con los costos que esto conlleva para las organizaciones. Vinculado con lo anterior está el problema del desaprovechamiento del conocimiento. Hay casos en que existe dentro de la empresa alguien o algo que puede ayudar a solucionar un determinado problema, pero por no saber de su existencia no se consulta. Con frecuencia las organizaciones no saben lo que realmente saben [8]. Este tipo de situaciones permiten vislumbrar como la AC podría ser de utilidad para dar soporte a algunos de los problemas del MS. Este trabajo propone la utilización de la AC como apoyo en la solución de este tipo de problemas. Primeramente se da una revisión del tipo de trabajo que se ha realizado para apoyar, por medio de la AC, a las organizaciones de desarrollo de software. Posteriormente se presentan dos casos de estudio realizado en dos grupos dedicados al MS. Por último se presenta brevemente el trabajo que estamos realizando para apoyar el proceso de mantenimiento de software por medio de la AC. 2 Administración del Conocimiento en el Desarrollo de Software Diversas organizaciones de desarrollo de software, han buscado mecanismos que les permitan aprovechar las distintas fuentes de conocimiento con las que cuentan, así como las lecciones aprendidas en proyectos anteriores. Como ejemplos de esto están: Sistemas de memoria organizacional. Que apoyan en la identificación y recuperación de fuentes de conocimiento. Por ejemplo expertos [9]. Reutilización de experiencias. Permite el aprovechamiento de las lecciones aprendidas durante los distintos proyectos realizados dentro de organizaciones de desarrollo software. Esto con el fin de mejorar la calidad y productividad de sus procesos y productos [10]. No obstante estos esfuerzos, no existen suficientes estudios de este tipo, que busquen solucionar los problemas del mantenimiento de los sistemas existentes. Por lo tanto, vemos la necesidad de desarrollar mecanismos que permitan aprovechar los beneficios que podría brindar la AC al mantenimiento del software. Para identificar qué tipo de problemas, y de qué manera pueden ser abordados por medio de la AC, hemos realizado dos casos de estudio en dos grupos de mantenimiento de software. 3 Casos de Estudio. Como mencionamos anteriormente, realizamos dos casos de estudio en dos grupos de MS [1]. El primero (grupo A) es un departamento que se encarga de dar mantenimiento a los sistemas administrativos utilizados por una institución de investigación y enseñanza superior. El segundo (grupo B), es una empresa que se dedica al desarrollo

3 de sistemas de administración telefónica. Los casos de estudio nos permitieron identificar los procesos principales que ambos grupos siguen durante el MS, por ejemplo, la atención de problemas de los usuarios; los tipos de solicitudes de cambios que manejan, así como la manera en que estas solicitudes son tratadas por cada uno de los grupos; y las actividades involucradas en las modificaciones dentro de los sistemas, como por ejemplo, los mecanismos de control de versiones de cada grupo. También se buscó identificar el tipo de actores y roles que participan en estas actividades, así como las fuentes de información y conocimiento que éstos consultan, y el tipo de conocimiento que requieren. Por último, se identificaron algunos de los problemas técnicos y sociales existentes en cada grupo. Encontramos que ambos esquemas tienen diferencias considerables, sin embargo, pudimos detectar que presentan problemas similares, por ejemplo, la falta de una buena documentación en los sistemas existentes, desaprovechamiento del conocimiento existente en cada grupo, y un alto riesgo de pérdida de conocimiento si alguno de los miembros del grupo lo deja. Además, pudimos observar que las fuentes de información y conocimiento que consultan son similares; con frecuencia consultan a otros miembros del grupo, al propio sistema (ejecutable y código fuente), la documentación que pudiera existir, y en el caso del grupo A, existe una comunicación constante con el usuario; lo que no sucede en el grupo B. Sin embargo, en la mayoría de los casos, el personal de mantenimiento se basa en su propia experiencia para resolver problemas. La Figura 1 muestra una generalización de estos aspectos. En ambos grupos, el ingeniero de mantenimiento (IM), primeramente debe recibir los requerimientos que deberán cubrir las modificaciones, así como un plan de proyecto en el que se establecen las tareas que debe realizar. Posteriormente, debe identificar las partes del sistema que requerirán ser modificadas, así como las que pudieran resultar afectadas. Para esto, el IM se basa principalmente en su experiencia, pero si ésta no es suficiente, consulta otras fuentes. Una vez que identifica las partes del sistema a modificar, y que obtiene una idea de qué cambios son los que debe hacer, procede a realizarlos. Código Fuente Documento Idea Documento de requerimientos Solicitud de mantenimiento Ejecutable Sistema Proyecto Requerimientos Identificar las partes del sistema que serán modificadas, y las que pudieran resultar afectadas Lista de módulos, tablas, reporte, etc. a modificar. Realizar modificaciones Usuario Documentación Otros miembros del equipo Ingeniero de mantenimiento Fig. 1. Aspectos a considerar antes de hacer las modificaciones al sistema, así como las fuentes de conocimiento consultadas por los ingenieros de mantenimiento. No obstante las distintas fuentes que pueden consultar los IM, en la mayoría de los casos se basan en la experimentación personal, por ejemplo, utilizando el sistema como si fueran usuarios del mismo, o analizando el código fuente, lo que por lo general consume bastante tiempo. Esto último es sobre todo cierto si no tienen conocimiento de la existencia de alguien o algo que pudiera ayudarles a resolver el problema. Por

4 ejemplo, detectamos que en ocasiones existen documentos o personas dentro del grupo, con la información o el conocimiento necesario para apoyar a otros en ciertas tareas, pero si estos últimos no lo saben, no los consultan. Un ejemplo de esto es una frase dicha por uno de los entrevistados: pero ella como iba a saber si yo no se lo digo. Los casos de estudio nos permitieron dar cuenta de la gran cantidad de diferencias que puede haber dentro de dos grupos de mantenimiento de software, sin embargo, también nos hicieron posible identificar problemas comunes que, consideramos, pudieran ser apoyados mediante la AC. Para ilustrar este tipo de problemas, planteamos diversos escenarios, dos de los cuales se presentan a continuación. 3.1 Escenarios El uso de escenarios es una técnica que permite la identificación de especificaciones de diseño de sistemas de software [14]. El tipo de escenarios presentados a continuación, nos ayudó a identificar los requerimientos básicos que, consideramos deben ser cubiertos por un sistema de AC que de soporte al mantenimiento de software. Escenario 1. Un IM debe implementar ciertos cálculos dentro del sistema de finanzas. Ya que su conocimiento en el área no es suficiente, las modificaciones le han tomado alrededor de una semana más del tiempo programado. Al cabo de esta semana, el jefe del departamento (JD), en una revisión del avance de los proyectos, detecta el retraso. Cita al IM para preguntarle la razón de dicho retraso. Cuando el IM le comenta cuál es el problema, el JD se da cuenta de que es algo en lo que él tiene experiencia, por lo que pude ayudar al IM a solucionar el problema ese mismo día. Escenario 2. Un IM sin mucha experiencia requiere modificar el formato de impresión del reporte de calificaciones por estudiante, el cual se encuentra dentro de la ruta: subsistema de la dirección de estudios de postgrado-> módulo de datos de estudiantes-> impresión de reportes-> reporte de calificaciones-> por estudiante. Para identificar cuáles son los archivos fuente que requerirán ser modificados, el IM tiene que entrar desde el menú principal, y seguir los archivos que son llamados a través de la ruta, hasta identificar el que corresponde con la opción reporte de calificaciones por estudiante. En contraste con lo anterior, cuando el IM tiene el conocimiento suficiente de la estructura interna del sistema, sabe cuáles son los archivos fuente que corresponden con la opción que se quiere modificar, por lo que no requiere hacer todo el seguimiento que hace un IM inexperto. En el primer escenario podemos ver que si el IM hubiera tenido la manera de saber que el JD tenía la experiencia para ayudarle a resolver el problema, posiblemente el retraso nunca se hubiera dado. Por otro lado, el segundo escenario permite observar que si el IM inexperto pudiera saber quienes han modificado con anterioridad un determinado módulo, y mejor aún, cuáles son los archivos que por lo general son modificados cuando deben hacerse cambios a éste, podría reducir el tiempo que dedica a la realización de los mismos. De estos dos escenarios surge la pregunta de cómo ayudar a los encargados del MS a identificar fuentes de conocimiento que les puedan ayudar en sus tareas, aun cuando estos no sepan siquiera que estas fuentes existen.

5 3.2 Características básicas para una herramienta de AC en el mantenimiento de software: Agentes de Software, una posible solución La información obtenida durante el caso de estudio, así como los distintos escenarios que fueron identificados, nos permitió hacer una recolección de los requerimientos básicos que, consideramos debe cumplir una herramienta de soporte a la AC que facilite la identificación de las fuentes de conocimiento en el MS. Entre estos requerimientos se encuentran: Apoyo en la identificación y acceso a fuentes de conocimiento (usuarios, personal de mantenimiento, documentos, etc.). Apoyo en la captura y recuperación de experiencias y casos similares. o Apoyo en la identificación de archivos fuente a modificar. o Apoyo en la identificación de módulos o archivos que pudieran resultar afectados por los cambios. El sistema debe ser pro-activo y autónomo. Los cuatro primeros requerimientos, fueron obtenidos de la literatura y los escenarios planteados en el presente artículo. Con respecto al quinto punto, consideramos que es necesario que el sistema sea capaz de apoyar en la generación e identificación de conocimiento y fuentes del mismo, sin la necesidad de una constante intervención del usuario, ya que, si a los IM se les solicita que para cada tarea que realicen, capturen información para incrementar la base de conocimiento, estos difícilmente encontraran una verdadera utilidad en el sistema. Además, vemos necesario que, aun cuando el IM no solicite directamente la búsqueda de fuentes de conocimiento, por ejemplo, por no saber que existen, el sistema sea capaz de anticiparse e informar al IM de la existencia de fuentes de conocimiento que pudieran ser relevantes para la tarea a realizar. Debido a esto, el sistema debe contar con cierta autonomía para actuar bajo determinadas circunstancias. Por a lo anterior, hemos considerado los agentes de software como tecnología para implementar el sistema de AC, ya que estos cuentan con características que los hacen viables en el desarrollo de sistemas autónomos y pro-activos [12], por lo que han sido utilizados en la implementación de sistemas de AC [11]. Cliente Ingeniero de Mantenimiento Interfaz de usuario Agente de AMC Personal AMFC Contenedor de agente de Personal Interfaz de usuario Repositorio Local Red Contenedor principal Agente de Directorio AMFC.- Agente manejador de fuentes de conocimiento AMC.- Agente manejador de conocimiento Servidor Contenedor de agentes de cliente Agente de Cliente Contenedor de agente de Producto Agente de Agente de Producto Proyecto AMFC AMC Repositorio Global Fig. 2. Arquitectura de agentes para la AC en el mantenimiento de software. Con esto en mente, hemos diseñado una arquitectura (Figura 2) basada en agentes para el desarrollo de sistemas de AC en el mantenimiento de software. La arquitectura

6 se compone de cinco tipos de agentes principales, que representan a los principales actores y elementos involucrados en el MS; además de dos tipos de agentes para apoyar en la generación y búsqueda de conocimiento, y en el manejo de las fuentes del mismo. Actualmente estamos desarrollando un sistema prototipo basado en la arquitectura de agentes propuesta, cuyo propósito es el verificar la factibilidad del desarrollo de sistemas de AC basados en ésta arquitectura, así como detectar a qué grado un sistema de esta naturaleza puede apoyar a los encargados del MS en la realización de sus tareas. 4 Conclusiones En el presente artículo, hemos propuesto la AC como un medio para apoyar en la solución de los problemas asociados al MS. La literatura revisada, así como dos casos de estudio realizados, nos hacen ver que la AC puede ser una alternativa viable para dar soporte a varios de los problemas presentes en el proceso de MS. Actualmente nos encontramos desarrollando un sistema basado en una arquitectura de agentes, que se encargue de gestionar el conocimiento generado durante la etapa de mantenimiento de software. Referencias [1] O. M. Rodríguez y A. I. Martínez. Caso de estudio: Mantenimiento del Software en el Departamento de Informática del CICESE. CICESE, Reporte Técnico, En revisión, [2] P. N. Robillard. The Role of Knowledge in Software Development. Communications of the ACM, 42(1): pp , [3] I. Rus y M. Lindvall. Knowledge Management in Software Engineering. IEEE Software, 19(3): pp , [4] R. Thomsett. The year 2000 Bug: A Forgotten Lesson. IEEE Software, 15(4): pp , [5] M. Polo, M. Piattini, y F. Ruiz. Using a Qualitative Research Method for Building a Software Maintenance Methodology. Software Practice & Experience, 32(13): pp , [6] IEEE. IEEE Standard for Software Maintenance (IEEE Std ), [7] S. Dart, A. M. Christie y A. W. Brown. A Case Study in Software Maintenance. Software Engineering Institute, Carnegie Mellon University. Technical Report, CMU/SEI-93-TR-8, [8] A. Tiwana. The Knowledge Management Toolkit: Practical Techniques for Building a Knowledge Management System. Prentice Hall, [9] M. S. Ackerman. Augmenting the Organizational Memory: A Field Study of Answer Garden. ACM Transactions on Information Systems, 16(3): pp , [10] V. R. Basili y C. Seaman. The Experience Factory Organization. IEEE Software, 19(3): pp , [11] C. Tacla y J. P. Barthès. A Multi-agent Architecture for Knowledge Management Systems. Second IEEE Intl. Symposium on Advanced Distributed Computing Systems. ISADS, [12] M. Wooldrige y P. Ciancarini. Agent-Oriented Software Engineering: The State of the Art. Springer-Verlang, Lecture Notes in AI, Vol. 1957, [13] R. C. Barquin. What is Knowledge Management?. Knowledge and Innovation: Journal of the KMCI, 1(2): pp , [14] J. M. Carroll y M. B. Rosson. Getting Around the Tast Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems, 10(2): pp , 1992.