Líneas de Producto de Software

Líneas de Producto de
Software - Introducción
Rubby Casallas
Departamento de Sistemas y
Computación
Universidad de los Andes, Bogotá
Referencias
[Pohl 2010]
[Clements 2002]
[Gomaa 2004]
[Northrop 2007]
Pohl K., Böckle G., van der Linden F.,
Requirements Engineering - Fundamentals,
Principles, and Techniques. Berlin. Springer, 2010
Clements, P. & Northrop, L. Software Product
Lines: Practices and Patterns. Boston, MA:
Addison-Wesley, 2002.
Gomaa, H. Designing Software Product Lines with
UML: From Use Cases to Pattern-Based Software
Architectures. Addison-Wesley Professional. 2004
Linda M. Northrop, Paul C. Clements. A
Framework for Software Product Line Practice,
Version 5.0. 2007.
Agenda
Definiciones:
Línea de producción vs línea de producto
Familia de productos
Línea de producción
Fábrica de software
Objetivos de las SPLs
Principios de la Ingeniería de Líneas de Producto
(Product Line Engineering- [Pohl 2010] Capítulo 1)
Productos individuales hechos a mano
Línea de producción: productos iguales en
grandes cantidades.
Disminución de costos a través de
estandarización
Reducción de posibilidades de diversificación
Línea de produción
Línea de produción
Línea de produción
Principios de la Ingeniería de Líneas de
Producto (Product Line Engineering)
Personalización en masa (Mass
Customisation):
Producción en gran escala de productos
adaptados/personalizados según necesidades de
clientes particulares
Ejemplos “Mass customization”
Ejemplos “Mass customization”
Principios de la Ingeniería de Líneas de
Producto (Product Line Engineering)
Personalización en masa (Mass
Customisation):
Producción en gran escala de productos
adaptados/personalizados según necesidades de
clientes particulares
Plataformas (Platform):
Una base tecnológica sobre la que se construye
otras tecnologías o procesos
Principios de la Ingeniería de Líneas de Producto
(Product Line Engineering- [Pohl 2010] Capítulo 1)
Qué ha pasado con el software?
Cuáles son los inconvenientes del sw
estandarizado (on the box) ?
Cuáles son los principales riesgos del
software “a la medida”?
Software Product Line SPL ([Clements
2002] capítulo 1)
“A software product line (SPL) is a set of
software-intensive systems that share a
common, managed set of features satisfying
the specific needs of a particular market
segment or mission and that are developed
from a common set of core assets in a
prescribed way.” [Clements 2002]
Línea de producto de software
“Una Línea de Productos de Software es un
conjunto de aplicaciones que comparten un
conjunto común y administrado de
características que satisfacen las
necesidades particulares de un segmento del
mercado o misión y que son desarrolladas a
partir de un conjunto común de activos
centrales en una forma prescrita” [Clements
2002]
Qué no es una SPL?
Reutilización fortuita de pequeñas partes de
código
Desarrollo de un sistema individual con
reutilización de partes de otro
Desarrollo basado en componentes
Arquitectura reconfigurable
Releases y versiones de productos
individuales
Conjunto de estándares técnicos
Reutilización de software
Experiencias?
Contexto
Qué, cómo
Dificultades, éxitos
“The interest of software product lines
emerged from the field of software reuse
when developers realized that they could
obtain much greater reuse benefits by
reusing software architectures instead of
reusing individual software components”
[Gomaa 2004] pag. 3
Beneficios SPLs [clements 20012]
Una línea de producto tiene éxito porque los
elementos comunes compartidos por los
productos de software pueden ser
aprovechados para lograr economías de
escala
Las compañías están encontrando que la
práctica de construir conjuntos de sistemas
relacionados a partir de activos comunes
puede producir mejoras considerables en:
Productividad, calidad, tiempo de salir al mercado
y satisfacción de los clientes
Beneficios SPLs
Significativo aumento de la productividad (un orden de
magnitud)
Reducción del tiempo para salir al mercado
Aumento de la calidad del producto
Disminución del riesgo del proyecto
Mayor satisfacción del cliente
Uso más eficiente de los recursos humanos
Capacidad para llevar a cabo la personalización en
masa del producto
Capacidad para mantener la presencia en el mercado
Capacidad para sostener un crecimiento sin
precedentes
Pero finamente ….
Cuáles son los “activos comunes” ?
Qué es lo que se reutiliza?
Además de reutilización qué más se
necesita?
Cómo se logran los beneficios?
Qué es lo que se reutiliza?
Los beneficios se logran a través de la
reutilización, en una forma estratégica y
prescrita, de activos (core assets)
Una vez que el depósito de activos es
establecido (plataforma según [Pohl 2010])
cada vez que un producto va a ser
construido, hay un ahorro directo asociado
con:
Cómo se logran los beneficios?
Qué es lo que se reutiliza?
Requerimientos
Arquitectura
Componentes
Modelamiento y análisis
Pruebas
Planeación
Procesos
Gente
Beneficios vs. Costos
tomado de: www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm
Costs and Benefits of Product Lines
Core Asset
Benefit
Additional Costs
Requirements: The requirements are Commonality and variation are
Capturing requirements for a group of
written for the group of systems as a
documented explicitly, which will help
systems may require sophisticated
whole, with requirements for individual lead to an architecture for the product
analysis and intense negotiation to
line. New systems in the product line will agree on both common requirements
systems specified by a delta or an
increment to the generic set.
be much simpler to specify, because the and variation points that are acceptable
requirements are reused and tailored. for all the systems.
The architecture must support the
Architecture: The architecture for the Architecture represents a significant
product line is the blueprint for how each investment by the organization's most variation inherent in the product line,
product is assembled from the
talented engineers. Leveraging this
which imposes an additional constraint
components in the core asset base.
investment across all products in the
on the architecture and requires greater
product line means that for subsequent talent to define.
products, the most important design
step is largely completed.
Software components: The software The interfaces for components are
The components must be designed to
components that populate the core
reused. For actual components that are be robust and extensible so that they
asset base form the building blocks for reused, the design decisions, data
are applicable across a range of product
each product in the product line. Some structures, algorithms, documentation, contexts. Variation points must be built
will be reused without alteration. Others reviews, code, and debugging effort can in or at least anticipated. Often,
will be tailored according to prespecified all be leveraged across multiple
components must be designed to be
variation mechanisms.
products in the product line.
more general without loss of
performance.
Beneficios vs. Costos
tomado de:
http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm
Performance modeling and
analysis: For products that must meet
real-time constraints (and some that have
soft real-time constraints), analysis must
be performed to show that the system's
performance will be adequate.
A new product can be fielded with high
confidence that real-time and distributedsystems problems have already been
worked out, because the analysis and
modeling can be reused from product to
product. Process scheduling, network
traffic loads, deadlock elimination, data
consistency problems, and the like will all
have been modeled and analyzed.
Reusing the analysis may impose
constraints on moving processes among
processors, creating new processes, or
synchronizing existing processes.
Business case, market analysis,
marketing collateral, and cost and
schedule estimates: These are the upfront business necessities involved in any
product. Generic versions are built that
support the entire product line.
All the business and management artifacts All these artifacts must be generic or be
involved in turning out the product line
made extensible to accommodate product
already exist at least in a generic form and variations.
can be reused.
Tools and processes for software
development and making changes:The
infrastructure for turning out a software
product requires specific product line
processes and appropriate tool support.
Configuration control boards, configuration
management tools and procedures,
management processes, and the overall
software development process are all in
place and have been used before. Tools
and environments purchased for one
product can be amortized across the entire
product line.
The boards, process definitions, tools, and
procedures must be more robust to
account for unique product line needs and
the differences between managing a
product line and managing a single
product.
Beneficios vs. Costos
tomado de:
http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm
Test cases, test plans, and test
data: There are generic testing artifacts
for the entire set of products in the
product line with variation points to
accommodate product variation.
Test plans, test cases, test scripts, and
test data have already been developed
and reviewed for the components that
are reused. Testing artifacts represent a
substantial organizational investment.
Any saving in this area is a benefit.
All the testing artifacts must be more
robust, because they will support more
than one product. In addition, they must
be extensible to accommodate variation
among the products.
People, skills, and training: In a
product line organization, even though
members of the development staff may
work on a single product at a time, they
are, in reality, working on the entire
product line. The product line is a single
entity that embraces multiple products.
Because of the commonality of the
products and the production process,
personnel can be more easily
transferred among product projects as
required. Staff expertise is usually
applicable across the entire product
line. Their productivity, when measured
by the number of products to which their
work applies, rises dramatically.
Resources spent on training developers
to use processes, tools, and system
components are expended only once.
Personnel must be trained beyond
general software engineering and
corporate procedures to ensure that
they understand software product line
practices and can use the core assets
and procedures associated with the
product line. New personnel must be
much more specifically trained for the
product line. Training materials must be
created that address the product line.
As product lines mature, the skills
required in an organization tend to
change, away from programming and
toward relevant domain expertise and
technology forecasting. This transition
must be managed.
SPLs Productividad
SPLs Productividad
Alcance de una Línea de Producto de
Software
Los productos que se pueden crear a partir
de la plataforma (depósito de activos) es el
alcance de la línea
Costo vs. Beneficios:
Si el alcance es muy amplio los beneficios se
verán disminuidos
Si el alcance es muy bajo los beneficios son altos
pero se corre el riesgo de producir pocos
productos