A Framework for Software Product Line Practice

1
A Framework for Software Product Line Practice

• Antti Raunio
• Martti Jansson
• Sami Hänninen
• Maria Pirhonen
• Ari Manninen

2
Contents

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

3
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.

4
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.

5
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)

6
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

7
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

8
PL Essential Activities

• Development process
• Core Asset Development
• Product Development
• Management

9
PL Essential Activities

• Core Asset Development process

10
PL Essential Activities

• Product Development Process

11
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

12
Product Line Practice Areas

• Software engineering practice areas
• Technical management practice areas
• Organizational management practice areas

13
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

14
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

15
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!

16
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

17
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 )

18
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.

19
Software System Integration

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

20
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.

21
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
  98.
• For the purposes of product lines, components are
  the units of software that go together to form
  whole system(products)

22
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

23
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

24
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

25
Example of a Product Line Architecture
Product Line Architecture
Server architecture
Web Container
EJB Container
Business logic
Business data
App.layer
Service layer
Databases
26
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

27
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

28
Example of Test Core Asset
Product architecture
Core Asset for internal self-testing
29
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

30
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!
31
CM Supported Tasks

• Parallel Development
• Distributed Engineering
• Build and Release Management
• Change Management
• Environment Management
• Process Management
• Object and Repository Management

32
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
33
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!

34
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

35
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
  stakeholders

36
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

37
How to choose?
Decision
Quality
Cost
Alignement with PL
Flexibility
Maintainability
Schedule
Requirements
Architecture
38
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

39
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
40
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

41
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

42
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

43
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

44
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

45
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

46
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 RD
  Group help the organisation avoid stagnation

47
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...

48
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

49
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
  activities

50
AcquisitionThe 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

51
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...

52
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
  cant support new technology, forecasting that is
  driven by technology (rather than business
  needs), ivory tower forecasting

53
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
  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

54
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

55
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

56
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/pd
  f/tr016.96.pdf

57
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

58
Products
59
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?

60
Establishing PL

61
System function is considered smallest unit of
reuse. (Despite it still consists of Ada units)
62
Architecture

• One of crucial elements in building PL
• Physical
• networks, processors
• Software
• Components, intercomponent coordination
• Division to layers

63
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

64
Architecture Layers 2/2
65
Product schedules
A is the basis of PL.
E, F, G take full advantage of PL
66
Number of system functions
67
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

68
Training
69
Technology changes
70
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

71
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

72
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?

73
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?

74
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

75
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

76
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