Presente y Futuro de
la Reutilización de Software

 

Qué es la
reutilización

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.

 

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…

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

[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