Transcript Framework for Sofware Product Line Practice

A Framework for Software
Product Line Practice
Antti Raunio
Martti Jansson
Sami Hänninen
Maria Pirhonen
Ari Manninen
Contents
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 assets
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 effort
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
determine:
Common capabilities across systems in the domains
and what variations are present
How subsets of capabilities might be packaged
together
Constraints(e.g. standards, legal restrictions,
business restrictions)
Which assets typically constitute members of
domains
Domain model is the baseline for the architecture
definition!
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 whole
Components-> subsystems ->products
Integration is considered in the
development of the production plan and
PL architecture
Software System Integration
Cost of integration will decrease over
completed projects/product
Interfaces have been defined and tested
Architecture has been fixed
In PL, emphasis is placed on planning for
integration.
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 parties[Szyperski 98].
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 components
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
architectures
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
easily
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
Client Architecture
Business Business
App.layer Service layerlogic
data
Databases
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
Testing
PL architecture supports testing by:
Enabling creation of test interfaces that allow
special access to the functionality of the subsystems
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
Configuration
management is
critical for product
line practice!
Higher quality with less effort
Minimize risk of errors
Eliminate confusion among team members
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
tabsetPanel
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 managed!
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
effort
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 ->
validity of metrics have not been
demonstrated
Measurement must consider the needs
of various stakeholders
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?
Decision
Quality
Cost
Alignement
with PL
Requirements
Flexibility
Architecture
Maintainability
Schedule
Product line scoping
Scope defines product line’s
Products
Goals
Future direction
Scope also describes
Market drivers
Nature of competing efforts
Other business goals for product line
Product Space
Asset Base:
Product Line:
product 2
Asset a
Asset b
Asset c
.
.
.
product 3
product 1
product 5
Product Space
product 4
product 6
product 7
product 8
product 2
product 5
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 it.
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 STRUCTURE?
Traditionally: software management at project level
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 organisation
Architecture group: product line architecture
definitions
Component engineering group: software core asset
development
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 group
Supplement groups: Technical steering group & R&D
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 current level of
organisational stress
The implementation history
Sponsorship
Resistance management
Culture
Change agent skills
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 line
how, who & what, when & in what order:
implementation / transition plan, specific product
development strategies and the role of aqcuisition
Product development:
Context, Activities, Organisational elements, Rationale, Integration
Core asset development: Components, Context, Activities,
Organisational elements, Rationale, Integration
Risks: failure to identify a PL champion, lack of
appropriate PL vision, failure to maintain the CONOPS
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 organisation’s
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 activities
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 acquisition
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,
CONFIGURATION MANAGEMENT, TRENDS WITHIN
THE RELEVANT STANDARDS
Risks: wrong technology choice, architecture can’t
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 development
In PL, the interfacing people include usually marketers, a
product manager, domain experts, a user’s 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
Funding
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 environment
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,
Teamwork
Forward-looking view, Global perspective, Shared
product vision
CASE: CelsiusTech Systems
A Case study in Successful Product line
development
By Lisa Brownsword and
Paul Clements
http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr016.96.pdf
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
Products…
Impetus for a PL approach
1986 two major contracts
CT found out, that it could’t carry out such
projects with current dev. methods
-> 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
Components, system functions
System function
is considered
smallest unit of
reuse. (Despite
it still consists
of Ada units)
Architecture
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 it’s 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
Training
Technology changes
Factors of success
Strong Management, a good vision
Crisis in the beginning was a good
”kick-off” -> 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-tomarket. Ability to enter new markets
quickly
SW/HW cost ratio inverted from 65:35
to 20:80
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?
Challenges
Practice sets additional constraint on the architecture
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
engineering
The quality of the core assets becomes absolutely
critical
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