Empecemos con una definición:
“Se define la reutilización de software como el uso de cualquier tipo de artefacto (también llamado activo), o parte del mismo, creado con anterioridad, en un nuevo proyecto.”
Qué se espera de esta práctica
CMM y CMMI [CMM] ya hablan de la práctica de reutilización de software; y lo hacen a todos los niveles, no solamente a nivel de código fuente. Estas buenas prácticas asociadas a la reutilización permitirán:
* Una reducción de los costes de desarrollo.
* Un aumento de la calidad de los productos.
* Un aumento de la Productividad, mediante la mejora de los tiempos en los que se desarrollan los nuevos proyectos informáticos (Time to Market TTM).
* Mejoras en las actividades de Mantenimiento y soporte de aplicación.
* Mejoras en las actividades de control y planificación por la reducción de desviaciones en los desarrollos.
Que inconvenientes muestra:
* Las técnicas tradicionales implican una alta inversión inicial, lo que dificulta el Retorno de Inversión (ROI).
* Nuevas herramientas y cambios en el proceso productivo avivan el ‘temor al cambio’.
La existencia de estos inconvenientes, unido con el hecho de que la tecnología de recuperación de activos no estaba preparada para solucionar la reutilización sistemática de artefactos, han hecho que la adopción de la reutilización en las organizaciones productivas haya sido moderada durante el siglo pasado.
Sin embargo, las condiciones han cambiado por fin, y mediante la creación de nuevas formas de aplicar el proceso de reutilización, así como la mejora en las tecnologías de recuperación de artefactos se pueden reducir los inconvenientes de forma drástica, y ¡mantener todas sus ventajas! Para ello vamos a ver como se reutilizaba en el siglo XX, y como se hace en el siglo XXI.
1.2 La reutilización en el siglo XX
En el siglo pasado resultaba imposible poder representar artefactos de software en un repositorio por su propio contenido (por ejemplo, buscar diagramas de clase similares a uno dibujado en mi herramienta CASE), lo cual impedía que cualquiera pudiera buscarlos sin conocimiento previo de su existencia.
Por este motivo, para reutilizar hubo que realizar el proceso inverso: primero parar la organización para ver qué podía ser reutilizable, después hacerlo reutilizable, lo siguiente era obligar a que todos conocieran lo que existe para reutilizar en la organización (puesto que sino NO sabrían que existía), y luego intentar obligar a que reutilizaran lo existente (bien en forma de patrones, líneas de producto, frameworks...) por lo que tendrían que saber operar con ellos de antemano. ¿Nos extraña que haya sido difícil implantar la reutilización?
El proceso de reutilización se presenta en la siguiente figura:
La pregunta, por lo tanto, es ¿cómo podemos acceder a los activos dentro del repositorio? Diferentes iniciativas han sido implantadas con diferente éxito. Entre ellas, los esquemas de clasificación más importantes han sido:
* Clasificación por keywords: a cada activo del repositorio se le otorga una serie de palabras clave, posteriormente, a través del interface de recuperación, el usuario que desea acceder a activos reutilizables tecleará el o los keywords que considere oportunos
* Clasificación facetada: supone un avance sobre el mecanismo anterior. La descripción de cada activo se organiza en una serie de valores ortogonales, para los que, a través de un tesauro, se habilitan una serie de keywords. De este modo, cada activo se clasifica en base al valor que toma en cada una de estas facetas. Posteriormente, el usuario que desea localizar activos no tiene más que incluir sus keywords en todas o algunas de las facetas del repositorio
Tras estas consideraciones, puede deducirse que el proceso de reutilización implicaba una costosa puesta en escena, y una dependencia fortísima de la tecnología de implementación, ya que únicamente se reutilizaban componentes ejecutables y nunca especificaciones de requisitos, pruebas, solución a riesgos…
1.3 La recuperación de información como elemento clave
Clasificación de activos en un repositorio orientado a su recuperación. Ya hace más de 10 años que Basili [BASI] creó una famosa taxonomía que definía las actividades a acometer para llevar a cabo la reutilización de software; sin embargo, esta idea vemos que sigue siendo la clave en los modernos repositorios de activos de software.
Tal y como puede verse en este figura, el proceso de reutilización se fundamentaba en la recuperación de activos en un repositorio y su posterior adaptación para el proyecto donde se deseen aplicar. Para lo cuál debemos partir de un repositorio que nos permita identificar sus activos, de cara a poder evaluarlos y seleccionar el candidato ideal a formar parte de nuestro nuevo proyecto. Este proceso de identificación, a su vez, consta de los procesos de caracterización (keywords, facetas… o caracterización por su contenido en sí, como veremos más adelante), y del proceso de matching que permite en sí la localización de los activos clasificados.
1.4 ¿Basta con reutilizar código fuente?
Hasta hace poco tiempo, a todos se nos había enseñado que escribir código directamente a partir de un documento que describía vagamente las necesidades de usuario no era una buena idea. Sabíamos que teníamos que comenzar por una correcta captura de requisitos, identificar todos los interesados en el proyecto (stakeholders), modelar el negocio donde va a residir la futura aplicación, realizar diagramas de análisis, luego de diseño... Sin embargo, ¿se llevaban a cabo todas estas tareas?
La respuesta a esta pregunta resultaba ser un rotundo NO. Y prueba de ello puede ser, por ejemplo, The Chaos Report [CHAO].
Con esto en mente, ¿cómo era la reutilización de software que se aplicaba en aquellos tiempos? Claramente pasaba por reutilizar código fuente. Sin embargo, reutilizar código fuente es realmente problemático debido a:
* Alguien que quiera reutilizar código en antiguas plataformas de desarrollo (COBOL, FORTRAN, Lisp, C…) estaría perdido en los tiempos actuales.
* Algo más actual, los que apostaron por reutilización basada en componentes COM, CORBA [JACO] se encuentran hoy día con que la tecnología actual nos orienta hacia los Web Services: ¿cuál será dentro de 5 años?
Es obvio que debemos apuntar algo más arriba a la hora de reutilizar software. Es decir, cuanto más arriba subamos en el ciclo de vida, más valor tiene el activo a reutilizar, puesto que se ha requerido un mayor poder de abstracción para crearlo; y más independientemente somos de la plataforma tecnológica, lo que evita riesgos de obsolescencia antes de la reutilización.
1.5 La reutilización en el siglo XXI
Con vistas a minimizar los inconvenientes descritos anteriormente y potenciar las ventajas de la reutilización se deben modificar profundamente los puntos de vista anteriormente expuestos. En este sentido los fundamentos de la reutilización del siglo XXI deberían ser:
* No estar obligados a detener la organización, ni dedicar un equipo especial, para saber lo que ésta tiene. De hecho, sería de desear que no fuera necesario saber por adelantado lo que existe si no se desea gastar mucho dinero: que el proceso de reutilización pueda empezar desde cero.
* Intentar crear artefactos reutilizables solamente cuando se sepa que se van a reutilizar al menos una vez. Además, si es posible, que no se tenga que tener un equipo humano pensando qué artefactos construir, sino que se identifiquen desde el propio repositorio.
* No obligar a que nadie en la organización conozca la existencia de nada por adelantado, sino que se pueda buscar lo que necesita por contenido. En vez de obligar, ofrecer una ventana a buscar lo que cada uno desee.
* No tener restricciones en lo que se desee buscar (requisitos, diagramas UML, pruebas, manuales, código fuente, riesgos, planificaciones de proyectos, experiencias post-mortem, reglas de negocio, personas, etc..), siempre buscando por contenido.
* No cambiar el proceso de desarrollo de software (SDP) de la organización, usualmente centrado en el “Proyecto” y mantener sus fases: Especificaciones, Análisis del problema, Diseño detallado,…. de forma que no haya que invertir desmesuradamente en formación.
* Demandar la aplicación de la trazabilidad entre los resultados de las actividades: Requisitos con riesgos, casos de uso con pruebas: “trazabilidad total”.
* Como se mantiene el SDP clásico, ofrecer reutilización en cada una de estas fases.
* Y finalmente, obligar solamente a una cosa: a que una vez terminado el proyecto, y realizado el proceso de post-mortem (debriefing), éste quede indexado en el repositorio corporativo para futuras utilizaciones de los mismos u otros ingenieros.
Las ventajas de conseguir un proceso de reutilización basado en las premisas anteriores serían:
* Requiere muchísima menos inversión inicial, por lo que el ROI se consigue muy rápidamente.
* No requiere cambios sustanciales en la organización.
* No requiere procesos desmesurados de formación.
* No es tan crítica la necesidad de apoyo desde la dirección.
* El proceso de implantación es incremental.
* Está soportado por herramientas informáticas.
1.6 Reutilización de Diseños de SW
Como se ha aprendido sobradamente de experiencias anteriores, los esfuerzos en las técnicas y prácticas de la reutilización deben efectuarse aguas arriba en el ciclo de vida de desarrollo, dejando así de lado la reutilización más clásica de código fuente. Los intentos que pretendieron reutilizar código fuente se toparon siempre con los problemas asociados a la evolución funcional (nada permanece estático y las modificaciones resultan muy complicadas a nivel código), así como a la mera evolución tecnológica (imaginamos que ya habrán “disfrutado” de la simple migración de aplicaciones realizadas para la versión 1.0 del Framework de .Net a la versión 1.1. Pese a que es un mero cambio de maquina virtual, resulta a veces complicado hacer que el código de la versión anterior funcione correctamente).
El siguiente nivel de reutilización por encima del código fuente son los diseños que previamente se hayan efectuado. Cuando hablamos de reutilización de software y de diseños de software enseguida se nos vienen a la cabeza los patrones de diseño. La idea de los patrones fue introducida por Christopher Alexander [ALEX] en el dominio de la arquitectura, aunque hace ya años que la idea ha sido acogida en el diseño de software. “Cada patrón describe un problema que ocurre una y otra vez en un entorno dado, describiendo el núcleo de la solución al problema de tal forma que pueda ser empleada un millón de veces sin hacerlo dos veces de la misma forma”. Ya en el mundo del software, Gamma y su equipo, en el reverenciadísimo libro Patrones de Diseño: Elementos de Software Reutilizable Orientado a Objetos [GAMM] hacen una clasificación en patrones creacionales, estructurales y de comportamiento.
Posteriormente a este trabajo, se han creado cientos o miles de patrones. Algunos de ellos han sido ideados para ser reutilizados horizontalmente (es decir, con posibilidad de aplicar en diferentes dominios o sectores), ejemplos de ellos son los patrones de Java y otros muchos. Otros patrones han sido creados en el seno de sectores de trabajo concretos (reutilización vertical).
Es precisamente en estos últimos, los verticales, donde vamos a hacer énfasis. Si en tu organización sueles realizar desarrollos enmarcados en un mismo dominio (banca, telefonía, farmacia...) ¿cuántas veces has diseñado y desarrollado funcionalidad similar en diferentes aplicaciones? ¿Has reutilizado estos diseños? La respuesta a esta última pregunta suele ser un Sí rotundo, ya que todo el mundo reutiliza diseños y experiencias pasadas; sin embargo, su ámbito de actuación es reducido, y simplemente solemos reutilizar nuestros diseños o los diseños de nuestros colegas físicamente más cercanos. Sin embargo, cuando hablamos de reutilizar diseños y experiencias de otras personas, incluso de mi misma organización, la respuesta No es tan rotunda; y el porqué suele deberse a la carencia de tecnología que permita localizar diseños clasificándolos por su contenido en sí.
Para solucionar estos problemas, se requiere una tecnología que hasta la actualidad no ha existido en el mercado. Desde hace décadas existen repositorios documentales que incluyen fabulosas capacidades de búsqueda dentro de documentos, pero la tipología de estos documentos se reduce a archivos de texto, MS Word, HTML y PDF.
Sin embargo, para reutilizar diseños se hace necesaria la creación de repositorios con la siguiente funcionalidad:
* Almacén de modelos de software: este repositorio deberá permitir almacenar y gestionar modelos SW creados con herramientas CASE. Sin olvidar funcionalidad imprescindible como gestión de versiones y de accesos, gestión de configuración...
* Localizador de modelos por su similitud: al igual que motores como Google y otros repositorios documentales ayudan en la localización de documentos textuales, cuando nuestro repositorio de modelos sea lo suficientemente extenso, se requerirán técnicas de búsqueda para no perderse en el mismo. Llegados a este momento, se puede optar por la salida sencilla, y generar un motor de búsqueda que simplemente refleje los nombres de nuestras clases, atributos... y almacenarlos y reverenciarlos como si fuesen texto plano. Esto puede ser útil en documentos de texto, pero con la riqueza que nos otorgan lenguajes como UML [UML], esta solución se torna realmente deficitaria. Otras opciones de clasificación y recuperación pueden ser la descripción en texto plano (ambigua y que permite poca precisión en las búsqueda), la asignación de keywords a cada modelo (bastante simple, a la vez que pobre) o el uso de facetas [PRIE] (que requieren un nuevo esfuerzo de generación de dichas facetas, que no son más que parejas atributo-valor).
Pero todo lo anterior no sirve a nuestras necesidades. Se hace vital disponer de un sistema mucho más avanzado que permita discriminar, por ejemplo, el nombre de una clase del nombre de un atributo, y que permita incluir la rica semántica que UML aporta a las relaciones dentro del motor de búsqueda. De esta forma, uno podría diagramar, utilizando de nuevo UML, su consulta, y el sistema devolvería aquellos modelos cuyo contenido incluye a lo indicado en la consulta.
* Localizador y extractor automático de patrones: hacer un estudio para determinar cuáles son los patrones, tanto de análisis como de diseño, que más se repiten en nuestros modelos es una labor ardua y costosa. Necesitamos repositorios que nos solucionen esta labor y que, periódicamente, según se van introduciendo nuevos modelos al sistema, vaya sugiriendo automáticamente cuáles son los patrones de elementos interrelacionados que más se repiten en mis modelos. De esta forma, estos nuevos patrones formarán parte de la familia de patrones de la organización y serán reutilizables por cualquiera de sus diseñadores.
* Métricas: como todos los procesos, el proceso de la reutilización debe ser medido de forma apropiada. Entre otras muchas, la razón viene de la mano de poder medir el retorno de inversión, aspecto vital para conseguir el apoyo de la alta dirección en los procesos de reutilización de software.
Ya desde hace tiempo existe el concepto de Patrones de Análisis, en concreto fueron introducidos por Martin Fowler en su famoso libro Analysis Patterns [FOWL], así como el concepto de patrones de diseño. Se hace necesario, pues, un repositorio que permita almacenarlos, navegarlos, localizarlos y reutilizarlos. Si extendemos esto a la extracción automática de patrones y a la búsqueda dentro de modelos completos, este repositorio es imprescindible en cualquier gran organización.
Las factorías de software deberían estar clamando por este tipo de tecnología.
1.7 Reutilización de especificaciones de requisitos
Reutilizar elementos de diseño, o incluso de análisis es, como ya hemos visto, mucho más valioso que reutilizar código. Sin embargo, ¿por qué quedarnos ahí? ¿Por qué no intentar subir más arriba en el proceso de desarrollo de software e intentar reutilizar requisitos? A fin de cuentas, aunque algunos métodos digan que son ‘conducidos por caso de uso’, todos sabemos que el verdadero núcleo conductor de todo desarrollo de software deberían ser los requisitos. Son estos requisitos los que darán lugar posteriormente a una representación formal basada en casos de uso.
Pongamos en la palestra, por lo tanto, el concepto de Patrones de Requisitos. Un patrón de requisitos puede ser visto como un conjunto de requisitos reutilizable. Al igual que en puntos anteriores, podrán existir patrones horizontales (interoperables entre varios dominios, como por ejemplo los requisitos de seguridad del Common Criteria [COMM]) y patrones verticales (propios de un dominio dado).
Sin embargo, la idea de un simple conjunto reutilizable de requisitos vuelve a quedarse coja. Hay que tener en cuenta que un buen proyecto de software no solamente incluye requisitos, sino también, por ejemplo, riesgos derivados de estos requisitos, las pruebas a estos requisitos... Según nuestra apreciación, un patrón de requisitos debería estar compuesto por la siguiente información:
* El conjunto de requisitos, ya sean estos horizontales o verticales, junto con sus correspondientes tipos.
* Los riesgos que acecharán al proyecto por la simple y sencilla razón de que tiene que abordar uno o más de esos requisitos.
* La especificación de las pruebas que han de llevarse a cabo para validar que el nuevo sistema a construir cumple con lo indicado en los requisitos del patrón.
* Los diagramas de análisis que responden a estos requisitos: estructuras de clases, modelos de datos, diagramas de actividad o de interacción que resuelvan los requisitos…
* El conjunto de documentos que permita entender el contenido del patrón y que ayude a implementarlo correctamente.
Estos patrones son, sin duda, atractivos, pero requieren de unas herramientas CASE algo especiales. Sin ir más lejos, necesitamos de herramientas que soporten la fase de análisis de requisitos, la de análisis de riesgos, el modelado y la de modelado de casos de prueba. Pocas herramientas del mercado cubren todas estas fases, por lo que hay que recurrir a suites completas (lo que dispara enormemente el precio). Pero no basta con soportar todas estas fases, además los elementos generados en cada una de ellas deben poder ser trazados con el resto de elementos, por lo que las herramientas deberán soportar un sistema sencillo, a la vez que potente de traza entre los distintos elementos.
Esta traza es vital para una reutilización efectiva de software a alto nivel basada en patrones de requisitos. Pero sería aún más importante si nuestra herramienta permitiese la localización semántica dentro de un repositorio que albergase todos los requisitos tratados en todos los desarrollos de tu organización. En ese caso, un modelo de software podría contener, no sólo requisitos, riesgos y casos de prueba, sino también análisis y diseños creados con UML, estimaciones, métricas... Tener toda esta información trazada, y disponer de herramientas avanzadas de búsqueda textual (basada en Procesamiento de Lenguaje Natural) sobre el contenido de los requisitos es un punto clave para disparar los beneficios de la reutilización de software.
Una vez localizado un requisito reutilizable en el repositorio, se requieren herramientas que permitan navegar sobre la traza y determinar:
* Qué elementos trazados con el actual deseo reutilizar en mi nuevo proyecto: si tu herramienta CASE lo permite, estos elementos podrán ser riesgos, estimaciones, elementos de análisis y diseño, casos de prueba...
* Qué elementos trazados a cualquier nivel quiero poder reutilizar.
* Qué atributos del actual requisito deseo reutilizar en mi nuevo proyecto (p.e. su complejidad, coste estimado, estabilidad...).
De esta forma se estará automatizando al máximo la labor del reutilizador de software. Pero cuidado, no hay que descuidar dos tareas importantísimas para garantizar el éxito de un programa de reutilización:
* Conteo: hay que llevar métricas sobre quién genera elementos reutilizables, cuántas veces estos son reutilizados, quién reutiliza qué...
* Análisis post-mortem: de qué vale reutilizar información sobre un requisito o un riesgo si no sabemos, por ejemplo, si la estimación de esfuerzo del requisito fue finalmente acertada, o si la estrategia de mitigación de un riesgo fue la más correcta. Por ello, se requiere una nueva fase antes de dar por concluido un proyecto. Esta nueva fase, conocida como post-mortem o debriefing, permite verificar antes de dar por finalizado el proyecto, aquellos datos que fueron dados justo al comienzo. De esta forma nos aseguraremos de que estamos reutilizando la información acertada.
1.8 Las Unidades de Reutilización como solución al problema
Para la correcta implantación de una unidad de reutilización de software hay que cubrir varias áreas de interés, flaquear en cualquiera de ellas implicará, sin duda, una importante merma en la eficiencia de las actividades de reutilización.
1.8.1 Dominio
Como ya se ha comentado anteriormente, se requieren avanzadas herramientas de clasificación y localización de conocimiento para el acceso inteligente al repositorio de activos reutilizables. En este sentido, tesauros y ontologías son modos de ampliar la eficiencia de los sistemas de búsqueda (ver sección de Herramientas); asimismo, una correcta determinación del dominio de aplicación de un problema ayuda a conocer sus fronteras y mejora la comunicación entre todas las partes involucradas.
1.8.2 Proceso
Los procesos de desarrollo clásicos no sobreviven en entornos donde la reutilización es una premisa. Sin embargo, un cambio radical en los procesos de desarrollo puede ser catastrófico. Por ello se propone la metodología IRM (Incremental Reuse Method). En realidad no se considera metodología, sino una especie de Add-in de actividades que se montan sobre el proceso actual de cualquier organización, dándole un enfoque a la reutilización. IRM hace un especial énfasis en:
* Gestión de vocabulario: tal y como se expresó en la sección de Dominio, una correcta determinación del vocabulario del dominio de trabajo dará fluidez a la comunicación entre los interesados, y potenciará las herramientas de recuperación
* Post-mortem (debriefing): tras finalizar el proyecto, y antes de catalogarlo en el repositorio, se requiere repasar que toda la información que, en su momento será reutilizada, es correcta
* Catalogación (indización): se trata de una fase automática que incluye los activos del proyecto dentro del repositorio para su posterior recuperación
Tras esto, se requiere que en el resto de actividades del proceso de desarrollo (análisis, diseño, codificación…) se posean herramientas de búsqueda que permitan el acceso a activos ya catalogados y que puedan ser de interés en mi nuevo proyecto. Si, además, estos activos están trazados contra otros de aquél proyecto, el éxito está casi garantizado.
1.8.3 Roles
Un proceso de trabajo diferente, requiere de perfiles diferentes. IRM define los siguientes roles:
* Arquitecto de dominios: Como ya se ha comentado, las ontologías forman el núcleo del repositorio (dominio). Por ello, se requiere un rol con capacidad de liderar la construcción y evolución de las ontologías. No necesariamente será un experto en el dominio a construir, sino más bien un experto en la construcción de dominios. Por otro lado, determinará qué activos serán los utilizados para la construcción de las ontologías.
* Experto de dominio: Se encargará, junto con el arquitecto de dominios, de la construcción de la ontología. Será entrevistado por éste y hará uso de las herramientas de trabajo colaborativo necesarias para la construcción y evolución de las ontologías. En la fase de construcción inicial de la ontología pueden utilizarse varios expertos de dominio, sin embargo, una vez construida la ontología, la dependencia de este rol se minimiza, siendo incluso suficiente con una única persona para la evolución del mismo.
* Catalogador: Es el rol encargado de incluir activos finalizados en el repositorio. Por lo tanto, se encargará de la fase de indización y de dar soporte al responsable de cada proyecto en la fase de debriefing. Asimismo, da soporte al resto de usuarios del sistema en la fase de recuperación y reutilización del conocimiento.
* Jefe de Unidad – Reuse Manager: Su misión es la de coordinar al resto de roles de la Unidad. Por ello, es el rol ideal para la comunicación con la dirección y la determinación de los objetivos; es decir, será el encargado de las actividades de gestión y de planificación (ver sección Sus actividades principales). También dentro de la actividad de Evaluación, se encargará de definir y corregir en su caso las métricas con las que se mide el proceso.
1.8.4 Herramientas
Como ya se ha comentado anteriormente, no basta con la iniciativa, la definición del proceso de desarrollo y la formación en reutilización; si no se dispone de las herramientas adecuadas, cualquier esfuerzo será en vano. La metodología IRM requiere de las siguientes herramientas:
* Gestión de ontologías: herramientas como domainREUSER son imprescindibles para la construcción y mantenimiento de tesauros y ontologías (representaciones de dominio). Sin embargo, hay que tener en cuenta que la construcción de dichos dominios podría llegar a automatizarse [TRC].
* Trazabilidad total: se requieren herramientas como swREUSER que permitan la trazabilidad total en el ciclo de vida de desarrollo
* Repositorio de activos reutilizables: este repositorio debe ser capaz de albergar cualquier tipo de artefacto, desde texto, hasta código, pasando por modelos software. Posteriormente, debe ser capaz de permitir el acceso a su contenido basándose en un simple y potente interface de recuperación. En este sentido REUSE Server es la herramienta ideal.
Autor: dTinf. The Reuse Company
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=reuse
Usuarios que han visto este tema también han visto...
- ¿Cuánto tarda en descargar una página web?
- Accesibilidad Sostenible
- Colores intermedios RGB
- Enlaces para ganar posiciones en buscadores
- Desarrollo de productos propios
- Versión imprimible de este documento
- Enviar por e-mail este documento
