2. Definition
A set of software-intensive system sharing a
common, managed set of features that satisfy the
specific needs of particular market segment or
mission and that are developed from a common set
of core assets in a prescribed way.
3. Introduction
A product line consists of :
multiple systems, which have the same architecture and
share common core assets
variability among systems
The three main goals of a software product line are
to reduce cost, improve delivery time, and improve
quality
It is a family of products designed to take
advantage of their common aspects and predicted
variabilities
4. Introduction Contd..
Market strategy/
Application domain
Architecture
Components
concern to
share an
are built from
is satisfied by
used to structure
Products
CORE
ASSETS
Product lines
take economic advantage of commonality
bound variability
5. Things which Make Software
Product Line Work
Reuse of followings:
Requirements
Architectural design
Elements
Modeling and analysis
Testing
Project planning
Processes, methods and tools
People
Exemplar systems
Defect elimination
6. Scoping
A product’s line scope is statement about what
systems an organization is willing to build as a
part of its line
Represents the organization’s best prediction
about what products it will be asked to build in
future
Lack of commonalities can be a problem in
defining the scope
7. Architectures for Product Lines
A product line architecture captures the
architectures of many related products
simultaneously
Generally employs explicit variation points in the
architecture indicating where design decisions
may diverge from product to product
A product line architect needs to consider 3 things:
Identifying variation points
Supporting variation points
Evaluating the architecture for product line suitability
8. Identifying Variation Points
• Variations discovered during requirement process :
Features, user interface, qualities, and target markets
• Variations points discovered during architecture design
process :
Either options for implementing the variations identified
during requirement process or normal variations during design
9. Supporting Variation Points
Inclusion or omission of elements
Inclusion of different number of replicated
elements
Selection of versions of elements that have the
same interface but different behavioral or quality
attribute characteristics
10. Evaluating the Architecture for
Product Line
Architecture is evaluated for its robustness and
generality
Evaluation process focuses on :
What to evaluate
How to evaluate
When to evaluate
11. Adoption Strategies
Top-down :
Manager orders to that the organization will use the
product line approach
Bottom-up :
Designers and developers begin to share resources and
develop generic core assets
12. Product Line Growth Models
Proactive product line :
Organization defines the family using comprehensive
definition of scope by taking advantages in the
application area
Reactive product line :
Organization builds the next member or member of
product family from earlier products
13. Evolving a Product Line
As time passes, the product line must evolve
Sources driving the product line evolution :
External sources :
Externally created element may be added to the product
line
Internal sources :
New functions may be added to the product and product
line may be updated
14. Benefits
Reduced Cost
Improved Time to Market
Flexible Staffing and Productivity
Increased Predictability
Higher Quality