Líneas de Producto Software aplicadas a la generación de blogs

innovación y desarrollo
Líneas de Producto Software
aplicadas a la generación
de blogs
Las LPS pueden engoblarse dentro de ese anhelo recurrente
de la ingeniería del software que es la reutilización
C
uando una empresa ofrece un
producto software a distintos
clientes, surge toda la problemática de las versiones y evolución acompasada del producto. En este escenario, no es raro
encontrarse con alguna de las siguientes
situaciones:
relaciones conflictivas entre los
equipos de marketing y de ingeniería a causa de la incapacidad
de los segundos para adecuarse a
las solicitudes de nuevas variaciones de producto provenientes del
negocio
coordinación compleja y costosa
de múltiples tareas de desarrollo
en paralelo que comparten software común
código fuente poco robusto, que
resulta difícil de extender con
variaciones del nuevo producto y
propenso al error.
Óscar
Díaz
Grupo ONEKIN –
Universidad del País
Vasco
En colaboración con LKS
Soc. Coop. y Donostia
Digital
Esta problemática no es exclusiva del
software. Se da también en la fabricación
de otros productos como automóviles,
aparatos de telefonía, electrodomésticos,
y en general, cuando un mismo producto
admite distintas variaciones. La producción en serie (mass production) – la capacidad para crear eficientemente múltiples
copias del mismo producto – constituyó
septiembre 2009 132
un gran avance en el mundo de la fabricación. Pero crear múltiples copias de un
producto software es trivial. Sin embargo,
la personalización en serie (mass customization) – la capacidad para crear eficientemente múltiples variaciones de un producto – es un importante reto tanto en la fabricación de lavadoras como en la venta de
un ERP o cualquier otro producto software. La pregunta es cómo se plasma el
enfoque de “personalización en serie” en
el desarrollo de productos software.
Ésta es la solución que pretenden
aportar las Líneas de Producto Software
(LPS). La característica que distingue
este enfoque es la reutilización proactiva. En lugar de agrupar los componentes de software en una librería, en espera de que puedan ser utilizados posteriormente (reutilización oportunista), el
enfoque LPS sólo crea aquellos componentes que sabe positivamente que van
a reutilizarse en uno o más productos de
la LPS.
la experiencia
Hemos aplicado estas ideas a la creación de una línea de productos para la
generación de blogs. Nuestro objetivo es
la creación de blogs a partir de los catálogos de productos de una empresa:
cada producto es un post del blog, las
innovación y desarrollo
Las LPS han vuelto a
recordarnos que la
reutilización eficaz no
es sólo un problema
técnico, sino también
de procesos y
organización
relaciones de cross-selling se soportan
como enlaces entre posts, y la participación de los clientes/socios pivota alrededor de los blogs a través de comentarios.
El objetivo no es realizar un blog, sino
una factoría de blogs. El dominio de aplicación son los blogs sobre catálogos de
productos (cataBLOGs), y sobre este
dominio surge una amplia casuística
(variabilidad) a considerar. En primer
lugar, la plataforma. Entre el amplio abanico de motores de blogs disponibles,
una primera decisión es la del almacenamiento. Los blogs pueden almacenarse
en remoto, y gestionarse on-line. Otra
opción es almacenarlo en local (standalone) y ser la propia empresa la que lo
gestione. Asimismo, los diferentes mecanismos de interacción entre los clientes
dan lugar a diferentes alternativas a la
hora de desarrollar el blog: posibilidad de
añadir comentarios de forma remota,
posibilidad de compartir posts fuera del
propio blog a través de herramientas de
bookmarking como delicious, posibilidad
de mecanismos de votación sobre diferentes aspectos de un producto, etc. A
esto habría que añadir variaciones en la
presentación y estética del blog. Todo
ello, definiría el espacio de diseño del
producto “blog”.
Los beneficios que las LPS aportan a
la calidad se pueden medir de dos maneras. La primera es el grado de exactitud
con que cada producto se ajusta a las
necesidades de cada consumidor. Las
capacidades de personalización de las
líneas de producto están dirigidas directamente a esta medida de calidad. La
segunda es la tasa de defectos encontrados en cada producto, también derivado
de que la LPS recoge todas las experiencias que se van obteniendo con la generación de cada producto. Optimizando la
reutilización de los elementos comunes a
lo largo de la línea de producto y durante
todo el ciclo de vida de la misma, emergen “assets” de una calidad muy alta.
Encontrar y arreglar un defecto en un
“software asset” común tendrá un impacto en todos los productos que usan ese
“asset”, aunque este defecto sólo se
hubiera observado en uno de ellos.
En el mundo web, con una tasa de
innovación muy alta, el time-to-market es
también un factor decisivo: ¿cómo puedo ahora ofrecer mi blog a través del
móvil? Las LPS ofrecen el marco para
capitalizar experiencias adquiridas en el
desarrollo de un producto singular pero
que pueden eventualmente repercutir en
productos ya existentes.
septiembre 2009 134
conclusiones
Las LPS pueden englobarse dentro
de ese anhelo recurrente dentro de la
Ingeniería del Software que es la reutilización. Este artículo ha motivado su interés
y brevemente ha expuesto las ventajas
que para el desarrollo software traen las
LPS a través de un caso real.
No nos gustaría terminar sin indicar
que la visión aquí dada es parcial. Nos
hemos centrado en las LPS como estrategia para la reutilización. Las LPS han
vuelto a recordarnos que la reutilización
eficaz no es sólo un problema técnico,
sino también de procesos y organización.
Las LPS suponen una importante reorganización de los equipos humanos. De
estar orientados al producto pasan a
pivotar sobre la LPS. Aquí pueden surgir
tensiones entre los desarrolladores de los
artefactos comunes frente a aquellos
encargados de desarrollar el producto
con estos artefactos. ¿Qué ocurre ante
nuevas peticiones del cliente no contempladas hasta entonces? Si la planificación no se cumple o se detecta algún
error, ¿a qué equipo se le imputa el coste? ¿Cómo se reparten las responsabilidades/presupuestos entre los dos tipos
de equipos? Pero esto es ya otra investigación…