Relación entre elementos de una Línea de Producto Software

Se profundiza ahora en la “relación” entre los componentes de una Línea de Producto Software, con la idea de expresar de un modo formal que dos productos P1 y P2 pertenecen a la misma familia. Para denominar esta relación, es bastante adecuado el concepto de analogía del diccionario de la Real Academia Española de la Lengua que define la analogía como “Relación de semejanza entre cosas distintas”. Los miembros de una Línea de Producto Software son por tanto análogos entre sí, ya que comparten los “activos básicos” de la Línea de Producto Software y se diferencian en lo específico de cada producto.

La analogía entre miembros de una Línea de Producto Software se puede establecer en diferentes ámbitos, por ejemplo Arquitectura Software, Especificación de Requisitos, Plataformas Hardware comunes, etc. Desde el punto de vista del método propuesto en la Tesis Doctoral, la analogía a nivel de Arquitectura Software no es relevante, aunque de hecho exista, puesto que se está considerando la Línea de Producto Software desde el punto de vista de las pruebas de sistema donde se prueba con el enfoque de caja negra y por eso la estructura interna de la implementación no es lo más importante. Sin embrago la analogía a nivel de Especificación de Requisitos sí que es relevante para el método de pruebas de la Tesis Doctoral, porque el método parte de los requisitos para definir todo el proceso de pruebas y si existe una relación de analogía entre los requisitos de cada producto, los casos de prueba de cada producto van a tener también aspectos en común que permitirán optimizar el esfuerzo en las pruebas de la Línea de Producto Software.

Una posible forma de comprobar que la analogía entre dos productos existe, considerando solamente los requisitos, sería decir que, dados dos los conjuntos de requisitos Pi del Producto i y Pk del producto k

Pi={R1,R2,....Rn} Pk={r1,r2,....rm}

hay analogía entre ambos si se verifica que

Pi ∩ _Pk ≠ 0 ⇒ _{Pi analogo Pk}

Pero esto último no tiene por qué cumplirse, si los requisitos son muy detallados y numerosos, como suele ser habitual en los sistemas reales. Una coincidencia en una pequeña funcionalidad no implica una semejanza significativa que permita concluir que los dos productos software pertenecen a una Línea de Producto Software. Para que dos productos sean análogos, deben de coincidir en un número muy significativo de requisitos. El problema de esta afirmación es que no se puede expresar de manera formal. Por eso es más adecuado definir formalmente la analogía basándolo en requisitos de carácter global o características (features) porque se puede describir las diferencias entre productos de una manera más abstracta y breve.

Las características o features es lo que se usa desde el punto de vista práctico para comunicar las diferencias entre las variantes de la Línea de Producto y se definen previamente a la especificación de requisitos, que es el punto de partida del desarrollo software. Se dice por ejemplo, que se quiere un

coche con elevalunas eléctrico (nivel de características o features) en lugar de decir un coche en el que al pulsar un botón de mando situado cerca de la ventana arranque un motor que mueva los cristales de la ventana con una velocidad determinada hacia arriba o hacia abajo según se haya pulsado (nivel de requisitos). Ejemplos de caracterización de variantes mediante características o features en la literatura son [Ka02] y [Ka90].

En conclusión, es posible definir formalmente la analogía entre componentes de una Línea de Producto Software en el nivel de las características o features. En el nivel de Especificación de Requisitos de Sistema establecer de modo formal una relación de analogía no parece tener mucha utilidad práctica, ya que existen muchos más requisitos que características o features y se tiene que adoptar, en mi opinión, un criterio más pragmático de tipo cuantitativo del tipo de establecer que un porcentaje mayoritario (un 80%) de los requisitos de la Línea de Producto Software debe de ser genérico y el resto puede ser diferente para cada una de las variantes.

Siguiendo las ideas de [Ei02] se puede elaborar una tabla de características (features) a partir de la cual se construye un gráfico en forma de árbol cuyos nodos son los llamados conceptos, formados por pares de productos y propiedades. Esto tiene interés para abordar la planificación del desarrollo y las pruebas de varios productos en paralelo con propiedades comunes. Para simplificar, no se tiene en cuenta las propiedades que se excluyen mutuamente, ni la distinta importancia que pueda tener una propiedad frente a otra.

El mapa de producto contiene todas las características de cada producto y se puede definir desde el punto de vista formal como una relación binaria M ⊆ Π x C entre un conjunto de productos Π y un conjunto de características C. La siguiente tabla es un ejemplo simple de mapa de producto:

Características

Productos almendras nata whisky helado chocolate bizcocho guindas

tarta reina X x x x

tarta

especial X x x x

tarta

suprema X x X x x

Tabla 3.1 Ejemplo de mapa de producto

Para un mapa de producto dado, las características comunes de un cierto conjunto de productos P ⊆ Π se define como σ(P):

σ(P)={c ∈ _C  _(p,c) ∈ Μ ∀ _p ∈ Π}

En el ejemplo, las características comunes de tarta reina y tarta especial son bizcocho, almendras,whisky.

Análogamente se define formalmente el conjunto τ(K) de productos comunes dotado de un conjunto de características K ⊆ C:

τ(K)={p ∈ Π  (p,c) ∈ Μ ∀ c ∈ C}

En el ejemplo los productos que tienen en común la característica whisky son tarta reina y tarta especial.

Para poder manejar desde un punto de vista formal los productos con características comunes, se define el concepto como una combinación de productos y características tales que todos los productos tienen todas las características y todas las características son comunes a todos los productos.

c=(P,K) si y solo si K=σ(P) y P=τ(K)

De forma intuitiva, el concepto sería en la tabla del ejemplo, un rectángulo con todas las casillas rellenas y donde las permutaciones de filas y columnas están permitidas. Volviendo al ejemplo, dos posibles conceptos son C1=({ tarta especial, tarta suprema},{ bizcocho, almendras, helado }) y C2=({tarta reina, tarta especial, tarta suprema},{bizcocho, almendras}). Comparando C1 y C2, se observa que los productos de C1 son un subconjunto de los productos de C2 y que las características de C2 son, a su vez, un subconjunto de las características de C1, por lo que se puede decir que C2 es más general que C1. Se puede representar la relación entre C1 y C2 con el signo ≤ de tal forma que:

C1=(P1,K1) ≤ C2=(P2,K2) ⇔ P1 ⊆ P2 y K2 ⊆ K1

Hay conceptos que no se pueden comparar usando la relación ≤. Por ejemplo entre C5=({tarta suprema},{ bizcocho, almendras, helado, chocolate, guindas}) y C1=({ tarta especial, tarta reina},{

bizcocho, almendras, whisky }), tanto C1 ≤ C5 como C5 ≤ C1 es falso, pues ni P1 ⊆ P5 ni P5 ⊆ P1. Basándose en esta relación “≤.“, [Ei02] propone construir con los conceptos un grafo acíclico cuyos nodos son los conceptos y una flecha une dos nodos cualesquiera Cx y Cz cuando Cx ≤ Cz. El grafo permite identificar al concepto más general de todos, pues es aquel del que sólo salen flechas y no entra ninguna. El problema que plantea [Ei02] se puede resolver también de manera no formal, inspeccionando la tabla de características manualmente o mediante un programa si la tabla es muy grande.

En conclusión, se define que los miembros de la Línea de Produto Software son análogos cuando existe un concepto general distinto del conjunto vacío que contiene las características comunes de la Líneas de Productos Software:

∃ Cx= (Px,Kx) ∧ Cx ≠∅∀ Ci = (Pi,Ki) ≠ Cx⇒ Ci≤ Cx

En sistemas reales no es trivial elaborar la tabla de características que en [Ei02] se toma como base para representar el mapa de producto, debido a que se precisa de un gran conocimiento del dominio para describir las características con el grado de abstracción adecuado y no todas las partes implicadas en una línea de productos (gestores, usuarios, desarrolladores, analistas funcionales, responsables de pruebas, etc.) tienen ese conocimiento.