Este documento describe las líneas de productos de software (LPS). 1) Las LPS buscan producir múltiples productos de software de manera eficiente mediante la reutilización masiva de activos de software comunes. 2) Esto permite entregar productos de software más rápido, económico y de mejor calidad. 3) Los beneficios incluyen reducciones en tiempo de mercado, costos, defectos y mejoras en calidad y tamaño de portafolio.

1. LÍNEAS DE PRODUCTOS DE SOFTWARE
Marcos Raúl Córdova Bayas
Facultad de Ingeniería de Sistemas, Escuela Politécnica Nacional
Campus “José Rubén Orellana”, Ladrón de Guevara E11-253, Quito, Ecuador
raul.cordova@epn.edu.ec
Resumen
El presente trabajo recopila el estado del arte de las Líneas de Productos de Software. Por mucho tiempo ha
existido la inquietud por reutilizar software, pero en la mayor parte de los casos, la reutilización ha sido
oportunista, es decir, ha surgido de la posibilidad de reutilizar componentes de software a posteriori, puesto que
no era algo que se supiera que se iba a poder reutilizar. Por ello, muchos esfuerzos de re-utilización no tenían el
éxito esperado, ya que no se conseguía reutilizar adecuadamente los productos previamente elaborados. Esta
situación cambia con las Líneas de Productos de Software. Ahora ya no se quiere producir un único producto, sino
una cadena de montaje que gestione eficiente y eficazmente las diferentes variaciones que pueden existir entre los
productos. Aparecen los conceptos de dominios y familias de productos, orientados a facilitar la reutilización de
productos de software de manera masiva, similar a la manera de fabricar productos en otras áreas, como en el
área automovilística o en la de construcción de todo tipo productos industriales. Para describir esta nueva manera
de desarrollar software, este trabajo contiene primero una Introducción a las Líneas de Productos de Software,
para luego definir los aspectos fundamentales que se deben seguir para insertar y adoptar esta práctica en las
empresas de desarrollo de software, como son los aspectos Conceptuales, Tecnológicos, Metodológicos,
Organizacionales y Gerenciales. Al final se listan las conclusiones obtenidas y la bibliografía consultada.
Palabras Claves: Reutilización de Software, Componentes de Software Reutilizable, Dominios de Software,
Familias de Software, Activos de Software, Líneas de Productos de Software, Fábricas de Software
Abstract
The present work compiles the state of the art of Software Products Lines. By long time there has been an
interest for reuse software, but in the majority of the cases, the reuse has been opportunist, in other words, it has
emerged from the possibility of a post reuse of software components, since it didn´t know that it could be reused. By
this reason, a lot of efforts to reuse didn´t have the expected success, since it didn´t properly achieve the reuse of
previously products produced. This condition changes with de Software Products Lines. Now we don´t want to
produce an only product, but an assembly line that manages in an efficient and effective way the different
variations between software products. So, now appears the concepts of product families and product scopes, tended
to facilitate the reuse of software products in a large-scale, as an assembly products in other areas, as in the
automotive area or as in a construction of different industrial products. To describe this new form to develop
software, this work first contains an Introduction to Software Products Lines, then define the basic aspects to follow
to insert and adopt this practice in software companies, like the Conceptual, Technological, Methodological,
Organizational and Managerial aspects. At the end, it lists the conclusions obtained and the bibliography
consulted.
Key words: Software Reuse, Reusable Software Components, Software Domains, Software Families, Software
Assets, Software Products Lines, Software Factories.

2. 1. Introducción las metodologías ayudaban a agilizar y sistematizar la
creación de un único producto. Existe una inquietud
Cuando una empresa ofrece un producto software a por reutilizar, pero en la mayor parte de los casos, la
distintos clientes, surge toda la problemática reutilización es oportunista, es decir, surgía la
relacionada al manejo de las versiones y a la posibilidad de reutilizar a posteriori, no era algo que
evolución del producto. En este escenario, no es raro se supiera positivamente que se iba a poder reutilizar.
encontrarse con alguna de las siguientes situaciones: Por ello, muchos esfuerzos de re-utilización no se
amortizaban ya que no terminaba de surgir la
• Relaciones conflictivas entre los equipos de oportunidad para poder reutilizarlo.
marketing y de ingeniería a causa de la
incapacidad de los segundos para adecuarse a las Esta situación cambia con las líneas de producto.
solicitudes de nuevas variaciones de producto Ahora ya no se quiere producir un único producto,
provenientes del negocio. sino una cadena de montaje que gestione eficiente y
eficazmente las diferentes variaciones que pueden
• Coordinación compleja y costosa de múltiples existir entre los productos. La empresa ya no se centra
tareas de desarrollo en paralelo que comparten en un producto para un cliente (por ejemplo, construir
software común. un portal para TAME), sino en un dominio (por
ejemplo, construir portales para líneas aéreas). El reto
• Código fuente poco robusto, que resulta difícil de está en delimitar el ámbito de este dominio, identificar
extender con variaciones del nuevo producto y las variaciones que se van a soportar, y dotarse de la
propenso al error. infraestructura que permita producir el producto a
bajo costo pero manteniendo alto nivel de calidad. Es
Esta problemática no es exclusiva del software. Se decir, aplicar los principios de la producción en serie
da también en la fabricación de otros productos como también al software. Este enfoque resulta en mejoras
automóviles, aparatos de telefonía, electrodomésticos, tanto en la eficiencia (reducción del time-to-market)
y en general, cuando un mismo producto admite como en la eficacia (mejora de la calidad del
distintas variaciones. La producción en serie (mass software). Entre los precursores de este enfoque en el
production) ––la capacidad para crear eficientemente mundo del software se encuentran McIllory (1968),
múltiples copias del mismo producto–– constituyó un Parnas (1976) y Neighbors (1989) que en sus trabajos
gran avance en el mundo de la fabricación. Pero crear ya intuían el potencial de estas ideas.
múltiples copias de un producto software es trivial.
Sin embargo, la personalización en serie (mass Las Líneas de Productos de Software (LPS) se
customization) ––la capacidad para crear engloban dentro del anhelo permanente dentro de la
eficientemente múltiples variaciones de un producto– Ingeniería del Software que es la reutilización. Pero
– es un importante reto tanto en la fabricación de mejorar la reutilización no lleva necesariamente a
lavadoras como en la venta de un ERP o cualquier reducir los costos globales de desarrollo debido a los
otro producto software. La pregunta es cómo se costos adicionales de desarrollar (y gestionar) estos
plasma el enfoque de “personalización en serie” en el artefactos re-usables. Las LPS han confirmado que la
desarrollo de productos software. reutilización eficaz no es sólo un problema técnico,
sino también de procesos y organización. El proceso
Si se mira al sistema de producción de las lavadoras, determina cuándo y dónde se debe realizar el esfuerzo
por ejemplo, la personalización en serie se consigue de reutilización. La decisión no es simple. De hecho,
mediante la introducción de la cadena de montaje o muchos de los fracasos en el desarrollo basado en
línea de producto. El objetivo: sacar partido de los componentes (también orientado a la reutilización), se
elementos comunes y gestionar de una manera eficaz deben a fallas en el proceso, más que en las técnicas
las variaciones. En lugar de permitir la máxima que se utilizaban: se invertían esfuerzos en hacer el
flexibilidad que permite el proceso artesanal pero con componente reutilizable para determinadas situaciones
grandes costes, las líneas de producto delimitan las que finalmente no se presentaban.
variantes de sus productos a un conjunto
prestablecido, y optimizan los procesos para estas Así mismo, las LPS suponen una importante
variantes. reorganización de los equipos humanos. De estar
orientados al producto pasan a orientarse a las Líneas
En la producción de software, el proceso ha venido de Productos de Software. Aquí pueden surgir
estando centrado en el producto antes que en la línea tensiones entre los desarrolladores de los artefactos
de montaje. Las herramientas de desarrollo (IDE) y comunes (o reutilizables) frente a aquellos encargados

3. de desarrollar el producto con estos artefactos. ¿Qué • Gestionada
ocurre ante nuevas peticiones del cliente no o Institucionalizada, sistemática,
contempladas hasta entonces? Si la planificación no se planificada, mejorada.
cumple o se detecta algún error, ¿a qué equipo se le
carga el costo? ¿Cómo se reparten las De las anteriores, la más utilizada ha sido la
responsabilidades/presupuestos entre los dos tipos de reutilización basada en oportunidad, donde los
equipos? componentes se almacenan en un repositorio a la
espera de una oportunidad de reutilización.
Este artículo comienza con una introducción a LPS,
luego se centra en sus aspectos conceptuales y Una de las técnicas más conocidas para el uso de la
tecnológicos, para luego tratar sus aspectos reutilización en software ha sido aquella basada en
metodológicos, organizacionales y gerenciales que componentes reutilizables, donde las aplicaciones se
permiten alcanzar los beneficios que esta nueva crean mediante la integración de componentes nuevos,
tecnología impulsa. Para terminar, se establecen las legados o de terceros conocidos como componentes
conclusiones del trabajo y se lista la bibliografía COTS (Commercial Off-The-Shelf).
consultada.
2.2 Definiciones de Línea de Productos de
2. Introducción a las LPS Software
En este punto se trata sobre lo que es una Línea de Las definiciones que se escriben a continuación son
Productos de Software, definiciones sobre LPS, el de los más autores más reconocidos en el ámbito de
modelo básico de la LPS, sus beneficios y sus las LPS:
aspectos fundamentales.
“Las Líneas de Productos de Software se
2.1 Línea de Productos de Software refieren a técnicas de ingeniería para crear
un portafolio de sistemas de software
La idea básica de las LPS es que se basan en el similares, a partir de un conjunto compartido
ensamblaje de partes de software previamente de activos de software, usando un medio
elaboradas, y está inspirada en la manera de realizar común de producción" (Krueger, 2006).
los procesos de producción de sistemas físicos, como
la producción de aviones, vehículos, computadores, ". Líneas de Productos de Software es un
aparatos electrónicos en general, etc. Está conjunto de sistemas de software que
fundamentada pues, en la Reutilización de Software y comparten un conjunto común y gestionado
asume la existencia de una industria de partes de de aspectos que satisfacen las necesidades
software. específicas de un segmento de mercado o
misión y que son desarrollados a partir de un
Los antecedentes de las LPS están en la reutilización conjunto común de activos fundamentales [de
de software; entre las definiciones más conocidas software] de una manera preescrita"
están de reutilización de software están: (Clements and Northrop, 2002).
“La reutilización de software es el proceso "Línea de Productos de Software consiste de
de implementar o actualizar sistemas de una familia de sistemas de software que
software usando activos de software tienen una funcionalidad común y alguna
existentes” (Sodhi & Sodhi, 1999). funcionalidad variable" (Gomma, 2004).
• La funcionalidad común descansa en el
"Reutilización de software es el proceso de uso recurrente de un conjunto común de
crear sistemas de software a partir de activos reutilizables (requisitos, diseños,
software existente, en lugar de desarrollarlo componentes, servicios web, etc.).
desde el comienzo" (Sametinger, 1997). • Los activos son reutilizados por todos
los miembros de la familia.
Existen varias modalidades de reutilización
utilizadas por las empresas de software: 2.3 El Modelo Básico de LPS
• Individual En la Figura 1 se muestra el Modelo Básico de una
• Oportunista Línea de Productos de Software (LPS).

4.  La entrega de productos de software de una
manera:
 más rápida,
 económica y
 con una mejor calidad
 Las LPS producen mejoras en:
 Tiempo de entrega del producto (time to
market)
 Costos de ingeniería
 Tamaño del portafolio de productos
 Reducción de las tasas de defectos
 Calidad de los productos
Figura 1. Modelo Básico de una Línea de Productos
de Software (LPS)  Beneficios tácticos y estratégicos (Krueger,
2006):
El modelo está constituido por:  Beneficios tácticos de ingeniería:
 Reducción en el tiempo promedio de
La entrada: Activos de Software (Software Assets creación y entrega de nuevos
Inputs): productos
 Reducción en el número promedio
• Una colección de partes de software de defectos por producto
(requisitos, diseños, componentes, casos de  Reducción en el esfuerzo promedio
prueba, etc.) que se configuran y componen requerido para desarrollar y
de una manera prescrita para producir los mantener los productos
productos de la línea.  Reducción en el costo promedio de
producción de los productos
El control: Modelos de Decisión y Decisiones de  Incremento en el número total de
Productos (Product Decisions: Decision Models productos que pueden ser
and Products Decisions) efectivamente desplegados y
• Los Modelos de Decisiones describen los mantenidos
aspectos variables y opcionales de los  Beneficios estratégicos de negocios
productos de la línea.  Reducción en el tiempo de entrega (time-
• Cada producto de la línea es definido por un to-market) y el tiempo de retorno (time-
conjunto de decisiones (decisiones de to-revenue) de nuevos productos
producto).  Mejoras en el valor competitivo del
producto
El proceso de producción (Production)  Márgenes mayores de ganancias
• Establece los mecanismos o pasos para  Mejor calidad de los productos
componer y configurar productos a partir de  Mejoras en la reputación de la empresa
los activos de entrada.  Mayor escalabilidad del modelo de
• Las decisiones del producto se usan para negocios en términos de productos y
determinar que activos de entrada utilizar y mercados
como configurar los puntos de variación de  Mayor agilidad para expandir el negocio
esos activos a nuevos mercados
La salida: Productos de software (Software  Reducción de riesgos en la entrega de
Product Outputs) productos
• Conjunto de todos los productos que pueden
o son producidos por la línea de productos.  Algunas empresas han reportado mejoras que
van en el rango de factores de 3 a 50 en los
2.4 Beneficios de las LPS beneficios discutidos anteriormente.
Entre los mayores beneficios de las LPS se pueden
anotar los siguientes:

5. 2.5 Aspectos fundamentales
En la Figura 2, se muestra el proceso de evolución
El paradigma de desarrollo de software LPS de la reutilización de software
requiere que las empresas que lo adopten consideren
los siguientes aspectos fundamentales: 3.1 Reutilización de software
La reutilización de activos de software en LPS tiene
a) Aspectos conceptuales varias características:
Conceptos en los que las LPS se fundamentan. a) Es estratégica, porque consolida lo común
b) Aspectos tecnológicos entre la línea de productos, maneja
Qué tecnologías son fundamentales para estratégicamente la variación entre los
desarrollar y mantener activos y productos de productos de la línea y elimina la duplicación
software de esfuerzos de ingeniería.
c) Aspectos metodológicos b) Es predictiva, porque la reutilización de
Cómo desarrollar y mantener los activos y activos se da en uno o más productos sobre
productos de software una línea bien definida y porque se reutilizan
d) Aspectos organizativos arquitecturas de software, en lugar de
Cómo debe la empresa organizarse internamente reutilizar componentes de manera
e) Aspectos gerenciales oportunista.
Cómo gestionar los proyectos de desarrollo de c) Es gestionada, ya que es sistemática,
activos y productos. planificada, institucionalizada y mejorada.
3. Aspectos conceptuales 3.2 Activos de software reutilizable
Un activo de software reutilizable es un producto
En este punto se tratarán los Aspectos Conceptuales de software diseñado expresamente para ser utilizado
que sirven de fundamento a las LPS y que tienen que múltiples veces en el desarrollo de diferentes sistemas
ver con la Reutilización de software, los Activos de o aplicaciones.
software, los Componentes de software reutilizable,
los Dominios y familias y las Líneas de productos de Un activo de software puede ser:
software. Su conocimiento permite a las  Un componente de software
organizaciones y profesionales involucrados en el área  Una especificación de requisitos
de Desarrollo de Software, entender las bases de las  Un modelo de negocios
LPS para poderlas aplicar en sus procesos de  Una especificación de diseño
producción de software.  Un algoritmo
 Un patrón de diseño (design pattern)
Reutilización de Software  Una arquitectura de dominio
 Un esquema de base de datos
 Una especificación de prueba
Desarrollo de Software
Basado en Líneas de  La documentación de un sistema
Productos  Un plan
3.3 Componentes de software reutilizable (CSR)
Desarrollo de Software Basado en
Componentes
Un componente de software reutilizable es “Una
pieza [de software] funcional que es liberada
independientemente [de otras] y que proporciona
Ingeniería de Ingeniería de acceso a sus servicios a través de sus interfaces”
Dominio Aplicaciones
(Brown, 2000).
Un componente de software puede ser liberado
Desarrollo de Desarrollo de (desplegado o instanciado) independientemente de
Software para Software con otros y ofrece servicios a través de sus interfaces, es
Reutilización reutilización decir, que para utilizar su funcionalidad se emplean
sus interfaces.
Figura 2. Evolución de la reutilización de software

6. Según el CBDi Forum, “Un componente es una
pieza de software que describe y/o libera un conjunto Redes de Servicios
de servicios que son usados sólo a través de interfaces
bien definidas” (CBDi Forum, 1999). Redes Otras
eléctricas redes
Así, un componente de software reutilizable (CSR)
debe ser: Acueductos Oleoductos
 Identificable
 Autocontenido
 Rastreable a través de su ciclo de desarrollo
 Reemplazable por otro componente
 Accesible solamente a través de su interfaz
 Inmutabilidad de sus servicios Figura 3. Ejemplo de dominio
 Documentación de sus servicios
 Mantenido sistemáticamente Una familia de productos de software es un conjunto
de productos de software asociados a un dominio
determinado.
 Clasificación de los Componentes de software
reutilizable (CSR)
Los miembros de la familia comparten aspectos
 Según su modificabilidad
comunes tales como un diseño arquitectónico común,
• Caja negra
un conjunto de componentes reutilizables,
• Caja blanca
capacidades y servicios comunes, y tecnologías
 Según su granularidad
comunes.
• Componentes de uso específico
• Componentes de negocio
• Marcos (frameworks)
3.5 Líneas de productos de software (LPS)
• Componentes de aplicación
 Según su fabricante
Una LPS es una familia de productos de software
• Componentes hechos en casa
que tiene un conjunto de aspectos gestionados que son
• COTS – Commercial Off-The-Shelf
comunes a todos los miembros de la familia, además
 Según la tecnología usada
de que los productos de la línea son desarrollados a
• Componentes imperativos
partir de un conjunto de activos de software
o Módulos, funciones
reutilizables.
• Componentes OO
o Clases
Una familia de productos de software tiene:
• Componentes distribuidos
• Aspectos comunes que son compartidos por
o Componentes CORBA
todos sus productos
o Componentes .NET
• Aspectos variables que establecen
o Componentes J2EE
diferencias entre los productos
o Servicios web
El objetivo principal de una LPS es reducir el
3.4 Dominios y familias
tiempo, esfuerzo, costo y complejidad de crear y
mantener los productos de la línea mediante la
Un dominio es un área de aplicación de productos
capitalización de los aspectos comunes de la línea de
de software que están centrados en torno a un cuerpo
productos, a través de la consolidación y reutilización
de conocimientos, tienen una economía de alcance
de los activos de entrada a la línea, y del manejo de
asociada que ocurre cuando al construirse un activo y
los aspectos variables de los productos de la línea, a
usarlo en múltiples productos ocasiona más beneficios
través de los puntos de variación de los activos y los
que crear el activo para cada producto y, que pueden
modelos de decisión (Krueger, 2006).
dividirse en subdominios. La Figura 3 muestra un
dominio sobre Redes de Servicios.

7. 4. Aspectos tecnológicos. 4.2 Repositorios LPS
En esta parte del documento se hablará sobre las Las líneas de productos de software requieren
Arquitecturas de LPS, los Repositorios de LPS y las almacenar sus activos de software en repositorios. Un
Áreas de prácticas y patrones para LPS. repositorio LPS es conocido como una base de datos
especializada, que almacena los activos de software y
4.1 Arquitecturas de LPS facilita la recuperación y el mantenimiento de los
activos de software. Su objetivo es asegurar la
Una arquitectura de software es la estructura o disponibilidad de activos para apoyar el desarrollo de
estructuras de un sistema que comprende los productos de la LPS. Su representación se la muestra
componentes del software, las propiedades visibles en la Figura 4.
externamente de estos componentes, y las relaciones
entre ellos (Bass, 1998).
Activos de
Las propiedades externas de los componentes son Software
sus interfaces (APIs) y sus características, como
rendimiento, manejo de errores, uso compartido de
recursos, etc.
Figura 4. Representación de los Activos de Software
La arquitectura de una LPS es una arquitectura de
software genérica que describe la estructura de toda la El repositorio mantiene información relevante de
familia de productos y no solamente la de un producto cada activo usado en la LPS, como la especificación
particular. Además, captura los aspectos comunes y técnica del activo, la historia o registro de uso, la
variables de una familia de productos de software. Los clasificación del activo y la documentación del activo.
aspectos comunes de la arquitectura son capturados
por los componentes de software que son comunes a Tipos de Repositorios LPS
toda la familia. Los aspectos variables de la
arquitectura son capturados por los componentes de Los Repositorios LPS se clasifican según su
software que varían entre los miembros de la familia. alcance, aplicabilidad y propósito de la siguiente
manera:
La arquitectura de una LPS también se la conoce
como arquitectura de dominio. Es importante acotar  Según su alcance
que la arquitectura LPS debe ser instanciada cada vez  Locales: son desarrollados y reusados
que se desarrolla un producto de la línea. Esta internamente por una organización o
instanciación se la hace a través de mecanismos de empresa.
variabilidad, que pueden ser:  Globales o de uso comercial: disponibles a
terceros bajo adquisición o subscripción.
 Herencia. Ej. Suplantación de un método  Ejemplos: COTS, Servicios Web.
heredado de una clase en un componente
 Puntos de extensión. Ej. Se agrega nueva  Según su aplicabilidad
funcionalidad o comportamiento a un  De dominio específico
componente.  De dominio general
 Parametrización. El comportamiento de un
componente puede ser parametrizado a tiempo de  Según su propósito
diseño y definido a tiempo de implementación.  De reuso: permiten el almacenamiento y
Ej. macros o templates. recuperación de activos de software
 Configuración. Selección y "deselección" de los  De referencia: facilitan la localización de
componentes de la arquitectura. activos en otros repositorios.
 Selección a tiempo de compilación. La  Ejemplo: UDDIs (siglas del catálogo de
implementación de una funcionalidad es negocios de Internet denominado Universal
seleccionada, entre varias posibles, al momento Description, Discovery and Integration).
de la compilación del componente o de la
aplicación. 4.3 Áreas de prácticas y patrones para LPS

8. La introducción del paradigma LPS en una empresa o La justificación del negocio.
de software es un proceso complejo, gradual y lleno o El proceso para describir el conjunto de
de dificultades. Para obtener los beneficios que este productos que serán incluidos en la línea
paradigma ofrece, una empresa debe tomar en de productos.
consideración los factores tecnológicos, A su vez, las áreas de práctica requeridas por la
metodológicos, organizacionales y gerenciales. solución son:
Así, Clements y Northrop (2002) definen un  Análisis del Mercado: ayuda a entender el
conjunto de áreas de prácticas y patrones que son mercado que tendrán los productos de la línea:
necesarios considerar para asegurar el éxito de la qué productos tienen mayor demanda, cuál es la
implantación del paradigma LPS en una empresa. competencia, cuál es el tamaño del mercado y
cuáles las oportunidades.
Un área de práctica es una colección de  Entendimiento de dominios relevantes:
actividades que una empresa debe ejecutar y dominar proporciona un modelo del dominio, los
para implantar exitosamente una LPS. Estas áreas de requisitos del dominio y los aspectos comunes y
práctica describen actividades que son normalmente variables a todos los sistemas (aplicaciones) que
recomendadas por el SEI (Software Engineering forman el dominio.
Institute), para el desarrollo exitoso de software y que  Proyección tecnológica: permite predecir qué
guardan una correspondencia estrecha con las áreas de productos pueden llegar a ser factibles en el
procesos definidas por el CMMI-SW (Capability futuro cercano.
Maturity Model Integration – Software).  Construcción de un caso de negocios:
proporciona una justificación de la selección de
Tres tipos de áreas de prácticas LPS son productos y del enfoque que se usará para
recomendadas por Clements y Northrop (2002): construirlos.
 Definición del alcance (scoping): describe
 Área de práctica de Ingeniería de Software. cuáles productos serán incluidos en la línea de
Ejemplos: Definición y evaluación de una productos y cuáles no.
arquitectura LPS.
 Áreas de práctica de Gestión Técnica. Ejemplo: 5. Aspectos Metodológicos.
Planificación de los proyectos de desarrollo de
componentes o de productos (aplicaciones). Los aspectos metodológicos de las LPS involucran
 Áreas de práctica de Gestión Organizacional. la aplicación de un conjunto de prácticas de
Ejemplo: Estructuración de la empresa ingeniería, como las siguientes:
Un patrón es una regla de tres partes que expresan  Definición de la arquitectura LPS
una relación entre un contexto, un problema y una
 Evaluación de la arquitectura LPS
solución (Alexander, 1979).
 Desarrollo de componentes
Los patrones LPS plantean soluciones a problemas  Utilización de COTS
recurrentes relacionados con las situaciones  Minería de activos existentes
organizacionales de las LPS. Estas soluciones son  Ingeniería de Requisitos
planteadas en términos de las áreas de prácticas y sus  Integración de sistemas software
relaciones. El siguiente ejemplo muestra las tres partes  Pruebas
del patrón “Qué construir”:  Entendimiento de dominios relevantes
 El Contexto: una empresa ha decidido crear una La Figura 5 muestra los procesos de negocio de una
línea de productos de software y conoce bien el LPS.
dominio de aplicación de los productos.
 El Problema: determinar qué productos deberán La Ingeniería de Dominio (ID) captura
ser incluidos en la línea de productos. información y representa el conocimiento sobre un
 La Solución: para determinar qué productos dominio determinado, con el fin de crear activos de
producir, se requiere información relacionada software reutilizables en el desarrollo de cualquier
con: nuevo producto de una LPS. Los productos de la ID
o El dominio de aplicación, la tecnología y son:
el mercado.

9. que se emplearán para producir los productos de
Activos de Productos de software.
Software Software
La Ingeniería de Aplicaciones (IA) se encarga del
Procesos LPS desarrollo de los productos de la LPS a través de la
reutilización de activos de software y de los planes de
producción.
Ingeniería de Ingeniería de
Dominio Aplicaciones
La arquitectura de dominio es empleada en la IA
como un modelo de referencia para diseñar los
productos de la LPS. A su vez, el repositorio LPS
Gestión Tecnológica
provee los activos requeridos durante el desarrollo de
cada nuevo producto de la LPS.
Algunos de los más conocidos Modelos de
Gestión Organizacional
Procesos para LPS son el Modelo TWIN, el Modelo
del SEI y el modelo ESPLEP (Evolutionary Software
Product Lines Engineering Process) propuesto por
Proceso de
Organización de Gomma (2004).
desarrollo la empresa
6. Aspectos Organizacionales
Figura 5. Procesos de negocio de una LPS
Los aspectos organizacionales están relacionados
con la organización misma de la empresa y con las
 Definiciones de dominios (descripciones del actividades que ella debe implantar para asegurar el
contexto) aprovechamiento eficaz y eficiente del paradigma
 Modelos del dominio LPS.
 Modelos de requisitos del dominio
 Modelos arquitectónicos (arquitecturas del Los aspectos organizacionales de las LPS
dominio) involucran la aplicación de un conjunto de prácticas
 Ontologías del dominio de gestión:
 Lenguajes del dominio
 Estándares del dominio  Construcción de casos de negocio
 Gestión de relaciones con los clientes
Las actividades principales de la Ingeniería de  Desarrollo de una estrategia de adquisición
Dominio son el Análisis de Aspectos, el Diseño de la  Análisis de mercados
Arquitectura LPS y la Implementación del Dominio.  Operaciones
 Planificación organizacional
El Análisis de Aspectos analiza la familia para  Gestión de riesgos organizacionales
determinar los requisitos que son comunes, opcionales  Estructuración de la empresa
y diferentes a todos sus miembros.  Proyección de tecnologías
 Capacitación de personal
El diseño de la Arquitectura LPS produce una
arquitectura de dominio que tiene componentes
comunes a todos los miembros de la familia, 7. Aspectos Gerenciales
componentes opcionales que son requeridos por
algunos miembros y componentes variantes, de los Están relacionados con la aplicación de los
cuales algunos miembros de la familia emplean procesos gerenciales en las actividades de Ingeniería
distintas versiones y tienen puntos de variación que de Dominio e Ingeniería de Aplicación de una LPS.
permiten configurarlos. Esto incluye:
La Implementación del Dominio consiste en la  Planificación de Proyectos
creación y almacenamiento de los activos de software  Organización de Grupos de Trabajo, que
pueden dividirse en Grupos de Soporte,

10. como el de la Administración de producto, además de la construcción de
Repositorios de Activos de Software y los herramientas de especialización o adaptación.
Grupos de Mantenimiento de Aplicaciones y
Grupos de Desarrollo, como los Grupos de
 Si bien las ideas aquí expuestas fueron
desarrollo de componentes y los de
desarrollo de aplicaciones. aparecieron hace ya más de 30 años, no es hasta
 Dirección hace poco más de diez años que estas ideas se han
 Administración de recursos evaluado en casos reales de cierta envergadura.
 Control Los resultados han sido muy esperanzadores y los
trabajos para profundizar en modelos de
Los aspectos gerenciales de las LPS involucran la organización, metodologías y técnicas adaptadas
aplicación de un conjunto de prácticas de gestión a las LPS son temas de interés creciente.
técnica:
 Gestión de la Configuración
 Recolección de datos, métricas y seguimiento
9. Referencias
 Análisis de
hacer/comprar/descubrir/encomendar
[1] Krueger, Ch. Introduction to Software
(aprovisionamiento de activos)
 Definición de procesos Product Lines. [On-line].
 Alcance www.softwareproductlines.com. 2006
 Planificación técnica
 Gestión de riesgos técnicos [2] Greenfield, J. et al. Software factories:
 Soporte de herramientas Assembling Applications with Patterns,
Models, Frameworks, and Tools. John
8. Conclusiones Wiley & Sons. 2004
 Las Líneas de Productos de Software representan [3] Gomma, H. Designing Software Product
el estado del arte en Reutilización de Software. Lines with UML: From Use cases to
pattern-based Software Architectures.
 La implantación del paradigma LPS en una Addison Wesley. 2004
empresa es un proceso complejo.
[4] Clements, P. and Northrop, L. Software
Product Lines: Practices and Patterns.
 Para manejar esta complejidad se requiere
Addison Wesley. 2002.
considerar diferentes aspectos: Conceptuales,
Tecnológicos, Metodológicos, Organizacionales y
[5] Montilva, J. Desarrollo de Software Basado
Gerenciales.
en Líneas de Productos de Software. [On-
line].
 Las LPS se pueden considerar como fábricas de http://www.ieee.org.ar/downloads/2006-
software, ya que poseen las mismas montilva-productos.pdf. 2012
características que las fábricas de productos
físicos, en donde los productos se elaboran [6] CBDi Forum. [On-line]. http://everware-
mediante las denominadas líneas de producción. cbdi.com/cbdi-forum. 1999.
 Las LPS tienen el potencial de disminuir costos y [7] Bass, Len et al. Software architecture in
practice. Addison-Wesley. 1998
tiempos de desarrollo de software, sin disminuir
su calidad.
[8] Brown A.W., Large-scale Component-Based
Development, Prentice-Hall. 2000.
 Las LPS implican la especialización en un
dominio y la construcción de un patrón de [9] Sodhi, Jag; Sodhi, Prince. Computer
software; Reusability. McGraw-Hill, New

11. York. 1999.
[10] Sametinger, J. Software Engineering with
Reusable Components. Springer-Verlag.
1997.
[11] Alexander, Christopher. A Pattern
Language: Towns, Buildings, Construction.
Oxford University Press, USA. 1979.
[12] McIlroy, Malcolm Douglas. Mass produced
software components. Software
Engineering: Report of a conference
sponsored by the NATO Science Committee,
Garmisch, Germany. 1968.
[13] Parnas David Lorge. On the Design and
Development of Program Families. IEEE
Transaction on Software Engineering. Vol. 2,
n. 1, 1976.
[14] Neighbors, James. Draco: A Method for
Engineering Reusable Software Systems.
Software Reusability, Volume I: Concepts
and Models, Ted Biggerstaff and Alan Perlis,
Editors, ACM Frontier Series, Addison-
Wesley. 1989.
[15] Díaz, O. Líneas de Producto de Software.
[On-line]. http://alarcos.inf-
cr.uclm.es/per/fruiz/cur/santander/odiaz-
lineasproducto.pdf. 2012