A Framework for Software Product Line Practice - PowerPoint PPT Presentation


PPT – A Framework for Software Product Line Practice PowerPoint presentation | free to download - id: 7c97ff-Nzg4Y


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

A Framework for Software Product Line Practice


Title: Framework for Sofware Product Line Practice Author: Sami Hanninen Last modified by: Sami Hanninen Created Date: 11/1/2000 3:51:53 PM Document presentation format – PowerPoint PPT presentation

Number of Views:79
Avg rating:3.0/5.0
Slides: 77
Provided by: Sami130
Learn more at: http://users.jyu.fi


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: A Framework for Software Product Line Practice

A Framework for Software Product Line Practice
  • Antti Raunio
  • Martti Jansson
  • Sami Hänninen
  • Maria Pirhonen
  • Ari Manninen

  • Introduction
  • Software Engineering
  • Technical Management
  • Organizational Management
  • CASE CelsiusTech Systems
  • Conclusion

What Is a Product Line
  • A product line is a group of products sharing a
    common, managed set of features that satisfy
    specific needs of a selected market or mission
  • Product line strategic reuse
  • Product lines promise to become the dominating
    production software paradigm of the new century.

Key Concepts I
  • Product line
  • A group of products sharing a common, managed set
    of features that satisfy specific needs of a
    selected market or mission area
  • Product family
  • A group of systems built from a common set of
  • Core asset
  • A software artifact that is used in the
    production of more than one product in a software
    product line. A core asset may be an
    architecture, a software component, a process
    model, a plan, a document, or any other useful
    result of building a system.

Key Concepts II
  • Domain
  • An area of knowledge or activity characterized by
    a set of concepts and terminology understood by
    practitioners in that area
  • Product Line Scope
  • Description of the products that will constitute
    the product line
  • Product Line Architechture
  • Description of the structural properties for
    building a group of related systems (i.e.,
    product line), typically the components and their
    interrelationships. The inherent guidelines about
    the use of components must capture the means for
    handling required variability among the systems.
    (Sometimes called a reference architecture)

How Does the Product Line Work
  • New product is formed by taking applicable
    components from the base of common assets
  • Components are tailored and new components are
    added if necessary
  • Assembled under the umbrella of a common,
    product-line-wide architecture.
  • The predominant activity in product creation is
    integration rather than programming

Why To Have Product Lines
  • Commonalities shared by the products can be
    exploited to achieve economies of production
  • Building sets of related systems from common
    assets can yield remarkable quantitative
    improvements in productivity, time to market,
    product quality, and customer satisfaction

PL Essential Activities
  • Development process
  • Core Asset Development
  • Product Development
  • Management

PL Essential Activities
  • Core Asset Development process

PL Essential Activities
  • Product Development Process

PL Essential Activities Management
  • Plays a critical role in the successful fielding
    of a product line
  • Activities must be given resources, coordinated,
    and supervised
  • Organizational management is responsible for the
    ultimate success or failure of the product line

Product Line Practice Areas
  • Software engineering practice areas
  • Technical management practice areas
  • Organizational management practice areas

Software Engineering
  • Practices necessary to apply the appropriate
    technology to create and evolve both core assets
    and products
  • Understanding relevant domains/domain analysis
  • Architechture definition
  • Architecture evaluation
  • Software system integration
  • Cots utilization/ Component development
  • Requirements engineering
  • Testing

Domain analysis
  • Includes
  • Identifying the areas(domains) that are useful
    for building the product(s)
  • Identifying the re-ocurring problems and known
    solutions within these domains
  • Capturing and representing this information in
    ways that allows it to be communicated to the
    stakeholders and used/reused across entire effort

Domain Analysis
  • Will produce a domain model which helps to
  • Common capabilities across systems in the domains
    and what variations are present
  • How subsets of capabilities might be packaged
  • Constraints(e.g. standards, legal restrictions,
    business restrictions)
  • Which assets typically constitute members of
  • Domain model is the baseline for the architecture

Inputs for a PL architecture Definition
  • Domain model
  • What is the playground
  • Product requirements
  • Uses PL scope as an input
  • PL Scope
  • Sets boundaries for PL
  • Existing assets
  • Will be analysed and generalized for use in the
    product line

Architecture Definition
  • Peculiarities in PL architecture
  • PL architecture is concerned with a set of
    explicitly allowed variations which, when
    instantiated, are products of PL
  • Integration has a greater role because of the
    number of products produced (integrated from core
    assets) in product line
  • Use span of the architecture is long
  • Architecture has to be flexible enough to enable
    possible changes in it ( in protocols, platforms )

Architecture Evaluation
  • Architecture is the key succes factor for the
    the Entire product line!
  • Evaluation will have to focus to variation
    points, that is, points in the arcitecture that
    will vary from product to product
  • Evaluation can lead to an expansion of the
    product line scope. Architecture may also have to
    be modified to be more sufficient.

Software System Integration
  • SSI refers to the practice of combining
    individual software components into an integrated
  • Components-gt subsystems -gtproducts
  • Integration is considered in the development of
    the production plan and PL architecture

Software System Integration
  • Cost of integration will decrease over completed
  • Interfaces have been defined and tested
  • Architecture has been fixed
  • In PL, emphasis is placed on planning for

Component development
  • A software component is a unit of composition
    with contractually specified interfaces and
    explicit context dependencies only. A software
    component can be deployed independently and is
    subject to composition by third partiesSzyperski
  • For the purposes of product lines, components are
    the units of software that go together to form
    whole system(products)

Component Development
  • The product line architecture shows variation
    points which are implemented using appropriate
  • The challenge of the component development is to
    produce reusable and adaptable components that
    will fill the technical requirements raised from
    variation needs

COTS Utilization
  • Commercial Off-The-Shelf -assets
  • Can be, for example, components, frameworks or
  • Both COTS and other assets should satisfy the
    variation needs inherent in the product line
  • Can set constraints for the architecture
  • E.g. Use of specific component model(DCOM, Java
    Beans, CORBA). Different models will not interact

Software development in product line
  • Parts of the product line
  • Overall architecture
  • Frameworks
  • Components
  • Process to integrate frameworks and components to
    a whole products within defined architecture

Example of a Product Line Architecture
Product Line Architecture
Server architecture
Web Container
EJB Container
Business logic
Business data
Service layer
Requirements engineering
  • Defines products and features of the products in
    the PL
  • Reqs. common across the entire product family
    constitute an important core asset
  • The PL scope and reqs. are tightly coupled and
    will evolve together
  • Requirements map the stakeholders needs to the
    evolving scope

  • PL architecture supports testing by
  • Enabling creation of test interfaces that allow
    special access to the functionality of the
  • These types of interfaces and functionality are
    often too resource intensive to be provided in a
    one-off systems
  • Enabling creation of test cases that are reused
    and used across the organization
  • Test architecture can be defined and included in
    the PL architecture so that test component(s) can
    become a core asset for a PL

Example of Test Core Asset
Product architecture
Core Asset for internal self-testing
Technical Management
  • Management practices necessary to engineer the
    creation/acquisition and evolution of the core
    assets and products
  • Configuration management
  • Measuring the product line
  • Make/Buy/Mine/Commision
  • Product line scoping
  • Technical Planning
  • Technical risk management
  • Tool Support

Configuration Management
  • Purpose
  • Establish and maintain the integrity of the
    products of the software project throughout the
    project's software life cycle
  • Configuration items of a project are first
    identified. Then changes to them are controlled
    and recorded.
  • Objectives
  • Higher quality with less effort
  • Minimize risk of errors
  • Eliminate confusion among team members

Configuration management is critical for product
line practice!
CM Supported Tasks
  • Parallel Development
  • Distributed Engineering
  • Build and Release Management
  • Change Management
  • Environment Management
  • Process Management
  • Object and Repository Management

Component Change Management
  • Changes can effect
  • a product specific component
  • a component used in many products
  • a core asset (most complicated)

Asset in use 1
Asset in use 2
Asset in use 3
Measuring the product line
  • Essential for product line decision making
  • Steps
  • Identify product line goals
  • Find indicators for goals
  • Define supporting measures
  • Establish performance baseline
  • Measurement activities should be planned and

What should be measured?
  • Core assets
  • Number and type
  • Cost of developing, evolving and sustaining
  • Reuse factors (actual and estimated)
  • Quality characteristics
  • Product development
  • Number of products and features
  • Complexity of requirements
  • Product specific reuse factor and development

Challenges for measurement
  • Up-front investment on measurement
  • Both the core assets and the application
    development must be measured
  • Product lines are a new practice -gt validity of
    metrics have not been demonstrated
  • Measurement must consider the needs of various

Ways to Attain Assets
  • Make Create the asset in-house
  • Buy Aquire off-the-self-components
  • Mine Develop assets from legacy systems
  • Commision Asset is built by a third party
    especially for the organization

How to choose?
Alignement with PL
Product line scoping
  • Scope defines product lines
  • Products
  • Goals
  • Future direction
  • Scope also describes
  • Market drivers
  • Nature of competing efforts
  • Other business goals for product line

Product Space
Product Space
Product Line product 2 product 5 product 8
Asset Base
product 2
product 3
Asset a
product 1
product 5
Asset b
Asset c
product 6
. . .
product 7
product 4
product 8
How To Scope?
  • Examine existing products
  • Conduct a workshop with stakeholders
  • Create
  • Context diagram What affects the product line
  • Attribute/product matrix How products in the PL
    differ from each other
  • Scenarios Find similarities in products

Technical Planning
  • Technical planning is the process by which plans
    are created
  • PL requires special plans for
  • Core asset development
  • How assets are created, tested, maintained,
    changed and funded
  • Production and reuse
  • Practices for asset adaptations, list of assets
    needed for certain product and actions for adding
    assets to the core asset base

Technical Risk Management
  • Technical risk management should provide
    processes, methods and tools to identify and
    assess what could go wrong and what to do about
  • Technical Risk Management Paradigm
  • Identify risks before they become a problem
  • Evaluate probability and impact
  • Plan actions
  • Track risk indicators
  • Control and take corrective actions

Factors for Product Line Practice
  • TRM is best implemented as an integral part of
    the project management
  • Product line requires also cross-project
    coordination of risk activities

Tool Support
  • There should be tools for
  • scoping
  • requirements engineering
  • architecture definition
  • component development
  • production plan practices
  • There is no single tool that addresses the needs
    of all PL practices
  • Tools must support concurrently creating,
    maintaining and using multiple versions of both
    PL assets and products
  • Interoperability between tools is critical

Organisational management practice area
  • How the organisation forms groups to carry out
    the various responsibilities inherent in a
    product line effort THE RIGHT ORGANISATIONAL
  • Traditionally software management at project
  • Product line new roles and responsibilities
    because of core asset management according to an
    application life cycle
  • Core assets need to be managed in a long-term
    life cycle this will benefit more the whole
    organisation than the specific product alone

Functional groups within a product line
  • Architecture group product line architecture
  • Component engineering group software core asset
  • Product line support group development and
    execution environments for product creation
  • Product development group products for customers
    and users
  • product-unique components, interaction with
    Component engineering group, feedback to Support
  • Supplement groups Technical steering group RD
    Group help the organisation avoid stagnation

Successful PL organisation
  • Separate or integrated groups? - At least someone
    must have a cross-product perspective
  • Success factors in implementing structural change
  • The highest risk building general assets too
    general and product-specific software too
    customized to serve the PL
  • The adoption of PL approach should be
    evolutionary a natural shift from the
    development of architecture to composition of new
    systems follows...

CONOPS - the operational concept for a product
  • how, who what, when in what order
  • implementation / transition plan, specific
    product development strategies and the role of
  • Product development
  • Context, Activities, Organisational elements,
    Rationale, Integration
  • Core asset development Components, Context,
    Activities, Organisational elements, Rationale,
  • Risks failure to identify a PL champion, lack of
    appropriate PL vision, failure to maintain the

Training and education
  • Training for asset development or aqcuisition is
    training in the software engineering practices
    within PL
  • Must occur within the context of the
    organisations adoption plan of PL practices
  • Must be applied in the context of overall PL
    strategy and specific training for certain
    practices must be tied to the goal of creating a
    core asset base to support the PL
  • Emphasis on effective use and reuse of assets
  • 1) Augmenting current training activities to
    support product lines, 2) Replacing existing
    training activities, 3) Adding new training

Acquisition The process of obtaining products and
services via contract
  • The development and maintenance should be
    systematically constrained by carefully
    specifying an architecture and a common asset
    base - the acquisition strategy must be generally
    compatible with PL practices!
  • Developing an acquisition strategy in PL is more
    critical than in a conventional system
  • If used in both core assets and product
    development, use a single strategy to ensure a
    unified approach

Business Case Market Analysis
  • Having capability resources, providing unique
    opportunity creating market demand, financing?
    Go / No go -questions
  • Also in determining whether to build a product
    using the core assets or construct it separately
  • Two cycles and as line products are developed,
    the document gets more tactical
  • Market analysis determines the PL scope and is
    itself a core asset, but maintained and updated
    as new products come, and gives detailed
    knowledge about the needs...

Technology forecasting
  • Internal development developing paradigms
    notations, technologies, code development suites,
    analysis tools, ...
  • Customer solutions more efficient hardware
    platforms, better software platforms, improved
    user interfaces,
  • Especially relevant to PLs PROCESS INNOVATIONS,
  • Risks wrong technology choice, architecture
    cant support new technology, forecasting that is
    driven by technology (rather than business
    needs), ivory tower forecasting

Customer interface management
  • In PL, it is different from single-system
  • In PL, the interfacing people include usually
    marketers, a product manager, domain experts, a
    users group coordinator, and others
  • New means for managing customer expectations,
    negotiating requirements, developing and evolving
    customer products and providing customer support
  • Managing requirements on a PL, not individual
    product, basis
  • Communicate PL strategy to the customer,
    establish a process for developing work proposals
    and negotiating new contracts, train marketers,
    provide centralized product support, establish a
    group to identify the needs

  • How PL assets (used across several products) are
    paid for equitably
  • PL often requires a substantial up-front
    investment to get the product line off the ground
  • FOCUS/Core asset development develop initial set
    of core assets production plan, define PL
    practices, develop software engineering
  • FOCUS/Product development develop a product,
    provide ongoing product support
  • Funding strategies depend on the fiscal
    infrastructure of the PL enterprise

Organisational risk management
  • PL efforts require a great deal of coordination
    across project boundaries
  • 7 principles Open communication
  • Continuous process, Integrated management,
  • Forward-looking view, Global perspective, Shared
    product vision

CASE CelsiusTech Systems
  • A Case study in Successful Product line
  • By Lisa Brownsword and
  • Paul Clements
  • http//www.sei.cmu.edu/pub/documents/96.reports/pd

Celsiustech AB
  • What is CT?
  • A Swedish naval defence contractor
  • Produces command-and-control systems using
    Product Line Approach
  • Customers Scandinavian, Middle Eastern and South
    Pacific navies
  • www.celsiustech.se

Impetus for a PL approach
  • 1986 two major contracts
  • CT found out, that it couldt carry out such
    projects with current dev. methods
  • -gt A demand for a product line approach
  • In addition, previous less-challenging projects
    had been over budget, past schedule So what
    would be the result of these major projects with
    old methods?

Establishing PL

System function is considered smallest unit of
reuse. (Despite it still consists of Ada units)
  • One of crucial elements in building PL
  • Physical
  • networks, processors
  • Software
  • Components, intercomponent coordination
  • Division to layers

Architecture Layers 1/2
  • Components are divided into layers
  • this is based on the type of information each
    layer encapsulates
  • Layers are ordered
  • HW-dependent, Middle, SW-specific layers
  • e.g. components specific to certain customer form
    a layer
  • Interaction between layers is restricted
  • component can access only components its own or
    next lower layer

Architecture Layers 2/2
Product schedules
A is the basis of PL.
E, F, G take full advantage of PL
Number of system functions
Things they had to cope with
  • Ownership changes
  • Technology changes
  • Learning new approach
  • 70 days of training to every employee
  • Teaching their approach to customers

Technology changes
Factors of success
  • Strong Management, a good vision
  • Crisis in the beginning was a good kick-off -gt
    idea of PL
  • Architecture was the foundation
  • Major investments in time, capital and resources

Lessons Learned
  • Building product line took a long time, but it
    was worth it
  • Reuse almost 80 , shorter time-to-market.
    Ability to enter new markets quickly
  • SW/HW cost ratio inverted from 6535 to 2080
  • Need of personnel decreased

Frequently Asked Questions I
  • If a product line is a set of products, does that
    mean I have to build them all?
  • Isn't product line practice the same as
    single-system development with reuse?
  • Isn't product line practice just another name for
    domain engineering/component-based development?
  • My organization is very small/very large. Can we
    build a product line?
  • The Software Capability Maturity Model V2 puts
    important aspects of product line practice at
    Level 4. Do I have to be at Level 4 before I can
    hope to field a product line?

Frequently Asked Questions II
  • We're doing okay. Why should I change the way I
    do business and undergo the upheaval that a
    product line will bring?
  • Where is the resistance to adopting a product
    line approach usually found?
  • What is the relationship between process
    improvement and product line practice?
  • Must all products in the software product line
    share the same architecture? If my products have
    different architectures but make heavy use of
    other shared assets, isn't that a product line?

  • Practice sets additional constraint on the
  • Components must be designed to be more general
    without loss of performance
  • Tools, methods and processes must be more robust
    to account for the differences between managing a
    product line and managing a single product
  • Personnel must be trained beyond general software
  • The quality of the core assets becomes absolutely

Criticism I
  • The article concentrates mostly on the management
    point of view. Software engineering is dealt only
    in general level
  • The article is comprehensive in its coverage, but
    it does not go very deep in any subject
  • Key concepts are defined too generally

Criticism II
  • The abstraction level is in some cases too high.
    There are no references to real-life case studies
  • There is no reference, what is the current state
    of the art in software engineering community
About PowerShow.com