Product Line Development: Software Engineering Approach to Embedded Systems Design

1
Product Line Development Software Engineering
Approach to Embedded Systems Design

• Srikanth Sastry

2
Outline

• Introduction
• Embedded systems and software engineering
• Product Line Development
• Current State of Practice and Trends
• Conclusion
• References
• Questions

3
Introduction

• Conventional Software Engineering processes
• Prescriptive
• Artifacts define assets
• Asset reuse is only one of, but not the primary
  goal
• Product goes through a development phase followed
  by maintenance phase
• New products repeat the entire software
  engineering process
• Costs involved are associated with software code
  and processes leading up to code generation
• These DO NOT apply to embedded system design!

4
Embedded Systems and Software Engineering

• Support a family of products
• Infrastructure that revolves around reuse
• Analysis of the commonality and variability of
  functional and structural properties of systems
• Account for costs involved in development of
  hardware and software
• Newer products need not go through the entire
  software development Life cycle
• Assets define artifacts
• This make the software engineering process
  descriptive!

5
Product Line Development

• A core idea
• Develop a reuse infrastructure that supports the
  software development of a family of products
• Key
• spend the resources in a way that promises a high
  return on investment and reduced time-to-market
• Three points of view
• Organization culture and processes
• Product Line Architecture
• Asset Management

6
Product Line Development

• Evaluation
• Analysis
• Implementation
• Asset Management

7
Product Line Development

• Analysis of the business case and the scope of a
  product line
• Analysis of domain knowledge
• Analysis of variability in time and space
• Architecture considered the first asset, from
  which the analysis of quality should reveal
  requirements conflicts and incomplete design
  descriptions from a particular stakeholder
  perspective

8
Evaluation Criteria

• Is Product Line Development suitable for the
  business idea?
• When, where and how could the product line
  approach be applied?
• What practices should be developed in order to
  achieve cost-effectiveness by a product line?

9
Suitability

• Identification of the business drivers and
  stakeholders
• Number of products that can be inserted into the
  product line
• Value of reusable assets
• Revenues from the product line
• Lack of experienced software engineers(?)

10
Suitability
11
Business Drivers

• Product Assortment
• Expected Sales
• Number of Products
• Value of reuse
• Similarity and Diversity of products
• Business Manners
• In-house components
• COTS components
• OCM (Original Component Manufacturers)
• Contracted Software

12
Business Drivers Organization culture and
processes

• Analyzes state of software development
  conformance between the described and applied
  software development practices
• Cultural differences in multi-site software
  development
• Current state of development process
• Component development, acquisition and
  utilization processes

13
Business Drivers Product Line Architecture

• Estimates the existing and predicted properties
  and quality of the products inserted into the
  product line
• Commonality and variability of the functional
  features
• Quality requirements of the products
• Artifacts and their representations
• Quality and documentation of Artifacts
• Business rationale cost, time-to-market,
  partnerships

14
Business Drivers Assets Management

• Estimates the potential to maintain assets by the
  developed and applied supporting mechanisms such
  as software and product configuration management
  (SCM, PDM)
• Mechanisms to manage variability inside the
  product line
• Mechanisms to share the properties of the product
  line with business stakeholders

15
Reality Check

• A good architecture needs well defined processes
  and supporting mechanisms for assets management
  in order to be successful
• The effort needed for the development of
  sophisticated software processes and assets
  management is essential in large, multi-site
  organizations, but a small company needs only a
  good architecture and simple practices and
  guidelines for the development and maintenance of
  assets.

16
Preconditions and Targets (When, Where and How? )

• Domain Analysis
• Domains and their scopes
• Commonalities and variability within domains
• Stability and maturity of domains
• Representations of reusable domain knowledge
• Quality of these representations
• Evolutionary or revolutionary approach
• Personnel Management
• Management
• Domain expertise
• Technical skills

17
Preconditions and Targets
18
Domain Analysis Organization culture and
processes

• Support for domain analysis
• Collecting and ordering domain knowledge
• Representations for knowledge management
• Individual and organizational readiness in
  product line development

19
Personnel Management Organization Structure
and Processes

• Commitment
• Decision making
• Roles, rights and responsibilities
• Expertise of software processes and metrics

20
Domain Analysis Product Line Architecture

• Quality requirements of the application domains
• Diversity of domains and implementation
  technology
• Standards
• Mapping domains to a product line architecture
• Domain rationale

21
Personnel Management Product Line Architecture

• Domain analysts
• Domain and product architects
• Dissemination of architecture
• Expertise of design and analysis of software
  architectures and components

22
Domain Analysis Assets Management

• Conceptual classification of the requirements and
  product features
• Models for representing and storing requirements
  and architecture into the core assets repository
• Models for storing documents of core assets

23
Personnel Assets Management

• Asset managers
• Distributed and virtual assets management
  infrastructure
• Expertise of data modeling and management

24
Development of core assets (Cost effectiveness in
a product line)

• Defining the software parts that are valuable to
  be considered as core assets
• Estimating the areas that require development
  effort the most
• Starts by an analysis of the current state of
  requirement definitions, software architecture
  and component descriptions, and of the processes
  concerning how they are developed.
• The parts of software (Not just code!) that have
  most potential for reuse are selected for core
  assets development

25
Development of Core Assets
26
Development of Core Assets

• Core assets engineering
• Definition of core assets of a domain
• Evaluation of the current state of core assets
• The characteristics of subsequent versions of the
  product line architecture
• Architecture styles and component models
• Design and analysis methods and tools of
  requirements, architecture and components
• A validated product line

27
Development of Core Assets (cont.)

• Evolution of core assets
• Management of product line development and
  product development (variability in space)
• Change Management changes of customers and
  end-users needs, problem domains, technologies
  and standards (variability in time)

28
Core Assets Engineering Organization Culture
and Processes

• Adaptation of methods and tools to organization
  settings
• Practices and metrics of product line processes
• Domain engineering process
• Component acquisition process and
• Product engineering processes

29
Evolution of Core Assets Organization Culture
and Processes

• Practices and metrics for the SCM process of the
  product line
• Practices and metrics for the PDM process of the
  product line

30
Core Asset Engineering Product Line
Architecture

• Adopted architecture design and analysis methods
  and techniques for the domain
• Architectural vision, styles and patterns of a
  domain
• Stable design centers with required variant
  aspects
• Adequacy of component models
• Design rationale, principles, concepts and rules

31
Evolution of Core Assets Product Line
Architecture

• Mapping variability in space and time to the
  product line architecture
• Principles and rules for the evolution of the
  product line architecture
• Reusability, modifiability and maintainability of
  a product line architecture

32
Development of Core Assets Assets Management

• Core Asset Engineering
• Initiating the core assets repository
• Principles, concepts and rules to store and
  retrieve core assets
• Evolution of Core Assets
• Mechanisms to manage variability in space and
  time

33
Current State of Practice and Trends

• Business Drivers
• Cost, quality and delivery are key drivers
• Software is a key part in all embedded systems
• when considering the initiation of a product
  line, reusability and modifiability are the most
  important business drivers
• in the initiation phase the amount of the
  required modifications is tried to be minimized
  while the reusability of the product line
  architecture is aimed to be maximized
• Product lines that have strong dependence on
  standards have well defined success criteria

34
Current State of Practice and Trends

• Broad assortment of products is deterrent in
  reusability
• Companies with expertise in the domain and
  architecture development, and a more flexible
  organization structure fare better
• Organizations with too many products or not well
  defined or informed success criteria were found
  to be lacking in commitment

35
Current State of Practice and Trends

• Evaluation of Preconditions and Domains
• Typical classification of domains
• User interface
• Data processing and management
• Real-time software
• Telecommunications software
• Hardware-related software
• A domain itself may also form a product
• A domain should be considered a separate software
  unit that has its own life cycle in the domain
  engineering and product engineering

36
Current State of Practice and Trends

• Domain knowledge is typically very high
• Hence, stability and maturity of application
  domains is very high
• But, knowledge representation and documentation
  is very poor or none at all
• Know-how of software architectures was identified
  to be inadequate
• Change management of artifacts properly defined
  and managed
• Changes in market segmentation not considered

37
Conclusion

• Product Line Software Engineering
• Useful while developing software for a family for
  products
• Based on the concept of Asset Management
• Reusability of assets, the primary objective
• Benefits
• Trying to catch the balance between sub-domains
  forces to consider the set of products instead of
  a product, and therefore, the important
  properties of a product line are most invested in
• The product line architecture is an investment
  that must be looked after

38
Conclusion

• The (sub) domains of a product line architecture
  may use, change and manage their own
  technologies, and evolve separately but in a
  controlled way. Hence, heterogeneous technologies
  can be used
• Evolution of a product line architecture can be
  managed through repositories that include
  requirement, features, architecture views and
  components
• Every partnership can select its own way to
  develop a product line and do business with it

39
References

• Niemela E.,  Ihme T., Product line software
  engineering of embedded systems , Proceedings of
  the 2001 symposium on Software reusability
  putting software reuse in context , 2001, pp.
  118-125
• Bosch, J. Design and use of software
  architectures. Adopting and evolving a product
  line approach Addison-Wesley, Harlow, 2000
• Dobrica, L., Niemelä, E. Product line
  architecture analysis. Submitted for 4-volume
  books on Software Architectures, Components, and
  Frameworks Fayad, M., Garlan, D. (eds.), 2001
• Schmid, K. Scoping software product line. An
  analysis of an emerging technology. In
  Proceedings of Software Product Line. Experience
  and research directions. Donohoe, P. (ed.),
  Kluwer Academic Publishers, Massachusetts, 2000,
  513-532.

40
Questions?