Software Product Lines

1
Software Product Lines

• SE540 Software Architecture
• Mark Ardis, Rochester Institute of Technology
• Fall 2007

2
Acknowledgements

• Some of the material in these slides is taken
  from Software Architecture in Practice, 2nd
  edition by Bass, Clements and Kazman.
• Some of the material in these slides is taken
  from Software Product Lines Practices and
  Patterns by Clements and Northrop.

3
Outline

• Motivation for Product Lines
• Paradox of Re-Use
• Architectural Support
• Challenges and Organizational Support

4
Airbus Beats Boeing in Huge Jetliner Deal with
USAir (11/6/96 NY Times)

• USAir, which had never bought a plane from
  Airbus, will purchase 120 Airbus A319s, A320s,
  and A321s...
• USAirs current fleet is a hodgepodge of nine
  types of aircraft
• A simplified domestic fleet would allow USAir to
  lower costs.
• Importance of Commonality
• USAir will reduce costs by using one aircraft
  type
• Airbus is reducing its production costs by
  reusing one aircraft type

5
Product Line Engineering
6
Economics Of Families

• Without Product-Line Engineering

With Product-Line Engineering
Cumulative
Cost
Number of Family Members
7
Re-Use Opportunities

• Requirements
• Architectural Design
• Software Elements
• Modeling and Analysis
• Testing

• Project Planning
• Processes, methods, tools
• People
• Exemplar Systems
• Defect Elimination

8
Failure of Re-Use

• If you build it, they will come.
• Re-Use libraries
• too sparse - not useful
• too rich - too difficult to search
• elements too small - easier to rewrite
• elements too large - too difficult to use
• architectural mismatch
• unknown pedigree

9
Success of Product Line Re-Use

• Context
• Architecture defined
• Quality attributes known
• Re-Use is planned
• Commonalities are known
• Application engineering is planned and supported

10
Scope How Big is the family?

• Consider market segmentation
• Customers should also have commonalities
• May need separate families for separate markets
• Consider supporting technology
• Narrow scopes can be automated more easily
• Broader scopes require more process discipline

11
Architectural Support for Variation

• Build process - include/exclude
• Build process - number of replicated elements
• Selection at compile or build - maintain
  interfaces but vary qualities
• Inheritance - allow different specializations
• Reflection - adapt to context
• Overloading - different types

12
Cartoon of the Day
13
Requirements for Success

• Software Engineering Practices
• Technical Management Practices
• Organizational Management Practices

14
Software Engineering Practices

• Architectural definition
• Architectural evaluation
• Component development
• COTS use
• Mining existing assets

• Requirements engineering
• Software system integration
• Testing
• Domain understanding

15
Technical Management Practices

• Configuration management
• Data collection and tracking
• Make/Buy/Mine analysis
• Process definition

• Scoping
• Technical planning
• Technical risk management
• Tool support

16
Organizational Management Practices

• Business case
• Customer management
• Acquisition strategy
• Funding
• Launching and institutionalizing
• Market analysis

• Operations
• Organizational planning
• Organizational risk management
• Organization structure
• Technology forecasting
• Training

17
Organizational Structures

• Development department (small)
• Business units (medium-sized)
• Domain engineering unit (large)
• Hierarchical domain engineering units(very large)