Avenida de Castilla,1 - Edificio Best Point - Oficina 21B28830 San Fernando de Henares (Madrid)

tel./fax: +34 91 675 33 06info@autentia.com - www.autentia.com

Somos su empresa de Soporte a Desarrollo Informático.Ese apoyo que siempre quiso tener...

1. Desarrollo de componentes y proyectos a medida

TecnologíaDesarrolloSistemas

Gran Empresa

Producción

autentia

Certificacióno Pruebas

Verificación previa

RFP Concurso

Consultora 1

Consultora 2

Consultora 3

Equipo propio desarrolloPiloto

3a

3b

1. Definición de frameworks corporativos.2. Transferencia de conocimiento de nuevas arquitecturas.3. Soporte al arranque de proyectos.4. Auditoría preventiva periódica de calidad.5. Revisión previa a la certificación de proyectos.6. Extensión de capacidad de equipos de calidad.7. Identificación de problemas en producción.

3. Arranque de proyectos basados en nuevas tecnologías

¿Qué ofrece Autentia Real Business Solutions S.L?

Para más información visítenos en: www.autentia.com

Compartimos nuestro conociemiento en: www.adictosaltrabajo.com

Gestor portales (Liferay)Gestor de contenidos (Alfresco)Aplicaciones híbridas

Tareas programadas (Quartz)Gestor documental (Alfresco)Inversión de control (Spring)

BPM (jBPM o Bonita)Generación de informes (JasperReport)ESB (Open ESB)

Control de autenticación y acceso (Spring Security)UDDIWeb ServicesRest ServicesSocial SSOSSO (Cas)

Spring MVC, JSF-PrimeFaces /RichFaces, HTML5, CSS3, JavaScript-jQuery

JPA-Hibernate, MyBatisMotor de búsqueda empresarial (Solr)ETL (Talend)

Dirección de Proyectos Informáticos.Metodologías ágilesPatrones de diseñoTDD

2. Auditoría de código y recomendaciones de mejora

4. Cursos de formación (impartidos por desarrolladores en activo)

2[12]

ÍNDICE

1 PRESENTE Y FUTURO DE LA REUTILIZACIÓN DE SOFTWARE........................................31.1 INTRODUCCIÓN A LA REUTILIZACIÓN ......................................................................................... 31.2 LA REUTILIZACIÓN EN EL SIGLO XX........................................................................................... 31.3 LA RECUPERACIÓN DE INFORMACIÓN COMO ELEMENTO CLAVE............................................................ 41.4 LA REUTILIZACIÓN EN EL SIGLO XXI ......................................................................................... 51.5 REUTILIZACIÓN DE DISEÑOS DE SW......................................................................................... 61.6 REUTILIZACIÓN DE ESPECIFICACIONES DE REQUISITOS.................................................................... 81.7 ¿QUÉ NECESITO PARA COMENZAR...? ¡¡¡ IRM Y SWREUSER LA SOLUCIÓN !!!¡ERROR! MARCADOR NO DEFINIDO.1.8 REFERENCIAS................................................................................................................... 11

3[12]

1 PRESENTE Y FUTURO DE LA REUTILIZACIÓN DESOFTWARE

1.1 Introducción a la reutilizaciónQué es la reutilizaciónEmpecemos con una definición:“Se define la reutilización de software como el uso de cualquier tipo de artefacto (también llamadoactivo), o parte del mismo, creado con anterioridad, en un nuevo proyecto.”

Qué se espera de esta prácticaCMM y CMMI [CMM] ya hablan de la práctica de reutilización de software; y lo hacen a todos losniveles, no solamente a nivel de código fuente. Estas buenas prácticas asociadas a la reutilizaciónpermitirá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 losnuevos 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 losdesarrollos.

Que inconvenientes muestra:Las técnicas tradicionales implican una alta inversión inicial, lo que dificulta el Retorno deInversió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 deactivos no estaba preparada para solucionar la reutilización sistemática de artefactos, han hecho quela adopción de la reutilización en las organizaciones productivas haya sido moderada durante el siglopasado.

Sin embargo, las condiciones han cambiado por fin, y mediante la creación de nuevas formas deaplicar el proceso de reutilización, así como la mejora en las tecnologías de recuperación de artefactosse pueden reducir los inconvenientes de forma drástica, y ¡mantener todas sus ventajas! Para ellovamos 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 XXEn el siglo pasado resultaba imposible poder representar artefactos de software en un repositorio porsu propio contenido (por ejemplo, buscar diagramas de clase similares a uno dibujado en miherramienta CASE), lo cual impedía que cualquiera pudiera buscarlos sin conocimiento previo de suexistencia.Por este motivo, para reutilizar hubo que realizar el proceso inverso: primero parar la organizaciónpara ver qué podía ser reutilizable, después hacerlo reutilizable, lo siguiente era obligar a que todos

4[12]

conocieran lo que existe para reutilizar en la organización (puesto que sino NO sabrían que existía), yluego 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 hayasido 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? Diferentesiniciativas han sido implantadas con diferente éxito. Entre ellas, los esquemas de clasificación másimportantes han sido:

Clasificación por keywords: a cada activo del repositorio se le otorga una serie de palabrasclave, posteriormente, a través del interface de recuperación, el usuario que desea acceder aactivos reutilizables tecleará el o los keywords que considere oportunosClasificación facetada: supone un avance sobre el mecanismo anterior. La descripción de cadaactivo se organiza en una serie de valores ortogonales, para los que, a través de un tesauro, sehabilitan una serie de keywords. De este modo, cada activo se clasifica en base al valor que tomaen cada una de estas facetas. Posteriormente, el usuario que desea localizar activos no tiene másque 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 costosapuesta 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 claveClasificación de activos en un repositorio orientado a su recuperación. Ya hace más de 10 años queBasili [BASI] creó una famosa taxonomía que definía las actividades a acometer para llevar a cabo lareutilización de software; sin embargo, esta idea vemos que sigue siendo la clave en los modernosrepositorios de activos de software.

5[12]

Tal y como puede verse en este figura, el proceso de reutilización se fundamentaba en larecuperación de activos en un repositorio y su posterior adaptación para el proyecto donde se deseenaplicar. Para lo cuál debemos partir de un repositorio que nos permita identificar sus activos, de cara apoder evaluarlos y seleccionar el candidato ideal a formar parte de nuestro nuevo proyecto. Esteproceso de identificación, a su vez, consta de los procesos de caracterización (keywords, facetas… ocaracterización por su contenido en sí, como veremos más adelante), y del proceso de matching quepermite 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 deun documento que describía vagamente las necesidades de usuario no era una buena idea. Sabíamosque teníamos que comenzar por una correcta captura de requisitos, identificar todos los interesadosen el proyecto (stakeholders), modelar el negocio donde va a residir la futura aplicación, realizardiagramas 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 realmenteproblemá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ásarriba subamos en el ciclo de vida, más valor tiene el activo a reutilizar, puesto que se ha requeridoun mayor poder de abstracción para crearlo; y más independientemente somos de la plataformatecnológica, lo que evita riesgos de obsolescencia antes de la reutilización.

1.5 La reutilización en el siglo XXICon vistas a minimizar los inconvenientes descritos anteriormente y potenciar las ventajas de lareutilización se deben modificar profundamente los puntos de vista anteriormente expuestos. En estesentido 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 éstatiene. De hecho, sería de desear que no fuera necesario saber por adelantado lo que existe si nose desea gastar mucho dinero: que el proceso de reutilización pueda empezar desde cero.

Reuse

Retrieve Modify

Identify Evaluate Select

Characterize Match

6[12]

Intentar crear artefactos reutilizables solamente cuando se sepa que se van a reutilizar al menosuna 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 quese pueda buscar lo que necesita por contenido. En vez de obligar, ofrecer una ventana a buscar loque 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 centradoen el “Proyecto” y mantener sus fases: Especificaciones, Análisis del problema, Diseñodetallado,…. 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 conriesgos, 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 elproceso de post-mortem (debriefing), éste quede indexado en el repositorio corporativo parafuturas 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 SWComo se ha aprendido sobradamente de experiencias anteriores, los esfuerzos en las técnicas yprácticas de la reutilización deben efectuarse aguas arriba en el ciclo de vida de desarrollo, dejandoasí de lado la reutilización más clásica de código fuente. Los intentos que pretendieron reutilizarcódigo fuente se toparon siempre con los problemas asociados a la evolución funcional (nadapermanece estático y las modificaciones resultan muy complicadas a nivel código), así como a la meraevolución tecnológica (imaginamos que ya habrán “disfrutado” de la simple migración de aplicacionesrealizadas para la versión 1.0 del Framework de .Net a la versión 1.1. Pese a que es un mero cambiode maquina virtual, resulta a veces complicado hacer que el código de la versión anterior funcionecorrectamente).El siguiente nivel de reutilización por encima del código fuente son los diseños que previamente sehayan efectuado. Cuando hablamos de reutilización de software y de diseños de software enseguidase nos vienen a la cabeza los patrones de diseño. La idea de los patrones fue introducida porChristopher Alexander [ALEX] en el dominio de la arquitectura, aunque hace ya años que la idea hasido acogida en el diseño de software. “Cada patrón describe un problema que ocurre una y otra vezen un entorno dado, describiendo el núcleo de la solución al problema de tal forma que pueda serempleada 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 SoftwareReutilizable Orientado a Objetos [GAMM] hacen una clasificación en patrones creacionales,estructurales y de comportamiento.

7[12]

Posteriormente a este trabajo, se han creado cientos o miles de patrones. Algunos de ellos han sidoideados para ser reutilizados horizontalmente (es decir, con posibilidad de aplicar en diferentesdominios o sectores), ejemplos de ellos son los patrones de Java y otros muchos. Otros patrones hansido 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ónsueles realizar desarrollos enmarcados en un mismo dominio (banca, telefonía, farmacia...) ¿cuántasveces has diseñado y desarrollado funcionalidad similar en diferentes aplicaciones? ¿Has reutilizadoestos diseños? La respuesta a esta última pregunta suele ser un Sí rotundo, ya que todo el mundoreutiliza diseños y experiencias pasadas; sin embargo, su ámbito de actuación es reducido, ysimplemente solemos reutilizar nuestros diseños o los diseños de nuestros colegas físicamente máscercanos. 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 lacarencia 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 enel mercado. Desde hace décadas existen repositorios documentales que incluyen fabulosascapacidades de búsqueda dentro de documentos, pero la tipología de estos documentos se reduce aarchivos de texto, MS Word, HTML y PDF.Sin embargo, para reutilizar diseños se hace necesaria la creación de repositorios con la siguientefuncionalidad:

Almacén de modelos de software: este repositorio deberá permitir almacenar y gestionarmodelos SW creados con herramientas CASE. Sin olvidar funcionalidad imprescindible comogestión de versiones y de accesos, gestión de configuración...Localizador de modelos por su similitud: al igual que motores como Google y otrosrepositorios documentales ayudan en la localización de documentos textuales, cuando nuestrorepositorio de modelos sea lo suficientemente extenso, se requerirán técnicas de búsqueda parano perderse en el mismo. Llegados a este momento, se puede optar por la salida sencilla, ygenerar 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 endocumentos de texto, pero con la riqueza que nos otorgan lenguajes como UML [UML], estasolución se torna realmente deficitaria. Otras opciones de clasificación y recuperación pueden serla descripción en texto plano (ambigua y que permite poca precisión en las búsqueda), laasignació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 queparejas atributo-valor).Pero todo lo anterior no sirve a nuestras necesidades. Se hace vital disponer de un sistemamucho más avanzado que permita discriminar, por ejemplo, el nombre de una clase del nombrede un atributo, y que permita incluir la rica semántica que UML aporta a las relaciones dentro delmotor 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álesson los patrones, tanto de análisis como de diseño, que más se repiten en nuestros modelos esuna 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 sugiriendoautomáticamente cuáles son los patrones de elementos interrelacionados que más se repiten enmis modelos. De esta forma, estos nuevos patrones formarán parte de la familia de patrones de laorganizació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 formaapropiada. 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 desoftware.

8[12]

Ya desde hace tiempo existe el concepto de Patrones de Análisis, en concreto fueron introducidos porMartin Fowler en su famoso libro Analysis Patterns [FOWL], así como el concepto de patrones dediseño. Se hace necesario, pues, un repositorio que permita almacenarlos, navegarlos, localizarlos yreutilizarlos. Si extendemos esto a la extracción automática de patrones y a la búsqueda dentro demodelos 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 requisitosReutilizar elementos de diseño, o incluso de análisis es, como ya hemos visto, mucho más valioso quereutilizar código. Sin embargo, ¿por qué quedarnos ahí? ¿Por qué no intentar subir más arriba en elproceso de desarrollo de software e intentar reutilizar requisitos? A fin de cuentas, aunque algunosmétodos digan que son ‘conducidos por caso de uso’, todos sabemos que el verdadero núcleoconductor de todo desarrollo de software deberían ser los requisitos. Son estos requisitos los quedará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 requisitospuede ser visto como un conjunto de requisitos reutilizable. Al igual que en puntos anteriores, podránexistir patrones horizontales (interoperables entre varios dominios, como por ejemplo los requisitos deseguridad 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 quetener en cuenta que un buen proyecto de software no solamente incluye requisitos, sino también, porejemplo, riesgos derivados de estos requisitos, las pruebas a estos requisitos... Según nuestraapreciació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 correspondientestipos.Los riesgos que acecharán al proyecto por la simple y sencilla razón de que tiene que abordar unoo más de esos requisitos.La especificación de las pruebas que han de llevarse a cabo para validar que el nuevo sistema aconstruir cumple con lo indicado en los requisitos del patrón.Los diagramas de análisis que responden a estos requisitos: estructuras de clases, modelos dedatos, 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 aimplementarlo 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 deanálisis de riesgos, el modelado y la de modelado de casos de prueba. Pocas herramientas delmercado cubren todas estas fases, por lo que hay que recurrir a suites completas (lo que disparaenormemente el precio). Pero no basta con soportar todas estas fases, además los elementosgenerados en cada una de ellas deben poder ser trazados con el resto de elementos, por lo que lasherramientas deberán soportar un sistema sencillo, a la vez que potente de traza entre los distintoselementos.Esta traza es vital para una reutilización efectiva de software a alto nivel basada en patrones derequisitos. Pero sería aún más importante si nuestra herramienta permitiese la localización semánticadentro de un repositorio que albergase todos los requisitos tratados en todos los desarrollos de tuorganización. En ese caso, un modelo de software podría contener, no sólo requisitos, riesgos y casosde prueba, sino también análisis y diseños creados con UML, estimaciones, métricas... Tener toda esta

9[12]

información trazada, y disponer de herramientas avanzadas de búsqueda textual (basada enProcesamiento de Lenguaje Natural) sobre el contenido de los requisitos es un punto clave paradisparar los beneficios de la reutilización de software.Una vez localizado un requisito reutilizable en el repositorio, se requieren herramientas que permitannavegar sobre la traza y determinar:

Qué elementos trazados con el actual deseo reutilizar en mi nuevo proyecto: si tu herramientaCASE lo permite, estos elementos podrán ser riesgos, estimaciones, elementos de análisis ydiseñ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 dereutilización:

Conteo: hay que llevar métricas sobre quién genera elementos reutilizables, cuántas veces estosson reutilizados, quién reutiliza qué...Análisis post-mortem: de qué vale reutilizar información sobre un requisito o un riesgo si nosabemos, por ejemplo, si la estimación de esfuerzo del requisito fue finalmente acertada, o si laestrategia de mitigación de un riesgo fue la más correcta. Por ello, se requiere una nueva faseantes de dar por concluido un proyecto. Esta nueva fase, conocida como post-mortem odebriefing, permite verificar antes de dar por finalizado el proyecto, aquellos datos que fuerondados justo al comienzo. De esta forma nos aseguraremos de que estamos reutilizando lainformación acertada.

1.8 Las Unidades de Reutilización como solución al problemaPara la correcta implantación de una unidad de reutilización de software hay que cubrir varias áreasde interés, flaquear en cualquiera de ellas implicará, sin duda, una importante merma en la eficienciade las actividades de reutilización.

Roles Herramientas

Proceso

Dominio

10[12]

1.8.1 DominioComo ya se ha comentado anteriormente, se requieren avanzadas herramientas de clasificación ylocalización de conocimiento para el acceso inteligente al repositorio de activos reutilizables. En estesentido, tesauros y ontologías son modos de ampliar la eficiencia de los sistemas de búsqueda (versección de Herramientas); asimismo, una correcta determinación del dominio de aplicación de unproblema ayuda a conocer sus fronteras y mejora la comunicación entre todas las partes involucradas.

1.8.2 ProcesoLos 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 sepropone 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 cualquierorganizació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 correctadeterminación del vocabulario del dominio de trabajo dará fluidez a la comunicación entre losinteresados, y potenciará las herramientas de recuperaciónPost-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 correctaCatalogación (indización): se trata de una fase automática que incluye los activos del proyectodentro 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 catalogadosy que puedan ser de interés en mi nuevo proyecto. Si, además, estos activos están trazados contraotros de aquél proyecto, el éxito está casi garantizado.

1.8.3 RolesUn 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 delrepositorio (dominio). Por ello, se requiere un rol con capacidad de liderar la construcción yevolución de las ontologías. No necesariamente será un experto en el dominio a construir, sinomás bien un experto en la construcción de dominios. Por otro lado, determinará qué activos seránlos 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 laontología. Será entrevistado por éste y hará uso de las herramientas de trabajo colaborativonecesarias para la construcción y evolución de las ontologías. En la fase de construcción inicial dela ontología pueden utilizarse varios expertos de dominio, sin embargo, una vez construida laontología, la dependencia de este rol se minimiza, siendo incluso suficiente con una única personapara la evolución del mismo.Catalogador: Es el rol encargado de incluir activos finalizados en el repositorio. Por lo tanto, seencargará de la fase de indización y de dar soporte al responsable de cada proyecto en la fase dedebriefing. Asimismo, da soporte al resto de usuarios del sistema en la fase de recuperación yreutilizació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 Susactividades principales). También dentro de la actividad de Evaluación, se encargará de definir ycorregir en su caso las métricas con las que se mide el proceso.

11[12]

1.8.4 HerramientasComo ya se ha comentado anteriormente, no basta con la iniciativa, la definición del proceso dedesarrollo y la formación en reutilización; si no se dispone de las herramientas adecuadas, cualquieresfuerzo será en vano. La metodología IRM requiere de las siguientes herramientas:

Gestión de ontologías: herramientas como domainREUSER son imprescindibles para laconstrucción y mantenimiento de tesauros y ontologías (representaciones de dominio). Sinembargo, hay que tener en cuenta que la construcción de dichos dominios podría llegar aautomatizarse [TRC].Trazabilidad total: se requieren herramientas como swREUSER que permitan la trazabilidadtotal en el ciclo de vida de desarrolloRepositorio de activos reutilizables: este repositorio debe ser capaz de albergar cualquiertipo de artefacto, desde texto, hasta código, pasando por modelos software. Posteriormente, debeser capaz de permitir el acceso a su contenido basándose en un simple y potente interface derecuperación. En este sentido REUSE Server es la herramienta ideal.

1.9 Referencias[ALEX] “A pattern language”. Christopher Alexander et al. Oxford University Press, 1977[BASI] “Support for comprehensive reuse”. V. R. Basili, H. D. Rombach. IEEE Software

Engineering Journal, 6(5):303–316, September 1991[CHAO] http://www.standishgroup.com[CMM] http://www.sei.cmu.edu/cmmi/[COMM] Common Criteria. ISO/IEC-15408:1999[FOWL] “Analysis Patterns: Reusable Object Models”. Martin Fowler. Addison-Wesley Professional,

1996[GAMM] “Design Patterns: Elements of Reusable Object-Oriented Software”. Eric Gamma et al.

Addison-Wesley Professional, 1995[PRIE] “A Faceted Approach to Building Ontologies”. Rubén Prieto-Díaz[TRC] http://www.reusecompany.com[UML] http://www.uml.org

dTinf. The Reuse CompanyAvda. Rey Juan Carlos I, 98, 4ºD

28916 Leganés, MADRIDSPAIN

| www.reusecompany.com | +34 91 680 90 22 | contact@reusecompany.com |

The Reuse Company, The Way to Reuse Knowledge and The Way to Reuse Software are trademarks of DTINF S.L. Copyright 2006.