Software Product Lines

From Suhrid.net Wiki
Jump to navigationJump to search

Intro

  • SW architecture is a big investment of time and effort usually by senior talent.
  • Maximize this return by reusing an architecture across multiple systems.
  • SW product line is a set of sw intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission. And are developed from a common set of core assets in a prescribed way.
  • Many products similar - planned rather than by accident.
  • Select components from a set of core assets.
  • Tailor assets - the mechanism is pre-planned. (e.g. parameterise)
  • Assemble rather than generate.
  • SW product lines simplify the creation of systems built specifically for customers or customer groups.

Core Assets

  • The essence of a sw product line is the disciplined, strategic reuse of assets.
  • Any artefact can be reused as an asset:
    • Requirements - Most of req's are common with earlier systems.
    • Arch. Design - Most imp design step already done.
    • Software components - Not just code reuse. Design processes, design successes reused.
    • Performance and modeling analysis - Perf models, schedulability analysis, distributed system issues.
    • Testing - Test plans, processes, cases, test data, harnesses etc.
    • Project planning - Budgeting, scheduling from pervious experience. Team size, composition.
    • Processes, methods and tools - Config control procedures and facilities, tools, coding standards.
    • People - transferred within projects.
    • Exemplar systems - Deployed products serve as high quality demo prototypes.
    • Defect elimination - Each new system takes adv of defect elimination of its forebears.
  • Reuse nomrally difficult. SW product lines make reuse work by establishing a very strict context for it.
  • Nothing is placed in the core asset library which was not built to be reused.

SW product lines are not

  • Fortuitous small scale reuse. For e.g. algorithms, libraries, objects.
  • Component or service based redevelopment - selecting components with no architecture focus.
  • Just versions of a single product.
  • Just a configurable architecture - much more than that.
  • Just a set of technical standards - constraining choices without an arch. based strategy.

Benefits and risks of product line

Benefits

  • Decreased cost
  • Decreased labour needs
  • Decreased time to market
  • Increased productivity
  • Improved quality
  • Ability to move into new markets

Risks

  • Is SPL appropriate ? Does it match the market ? Do products have sufficient commonality ?
  • Substantial up front cost in establishing core assets.
  • Does SPL match organisation structure ?

Core Product Line Activities

  1. Core Asset Development.
  2. Product Development.
  3. Technical and Organisational Management.
  • The order in which the above can be applied varies.
  • Build products from assets - Proactive approach.
  • Extract assets from products - Reactive approach.
  • Product development might create new, or refine core assets.

Core Asset Development

  • Inputs:
    • Product Constraints.
    • Styles, patterns and frameworks.
    • Production constraints.
    • Production strategy.
  • Outputs:
    • Product line scope
    • Core assets
    • Production plan

Product Development

  • Inputs:
    • Product requirements
    • Product line scope - Does the product fit within the scope ?
    • Core assets
    • Production plan - How the core assets are to be used to build the product.
  • Outputs:
    • Products.
    • New assets.
    • Product constraints.

Management

  • Commitment to effort essential.
    • Allocate sufficient resources.
    • Right allocation of resources/skills.
    • Funding may need higher level agreement as single product is unable to afford it.
  • Organisation of teams
    • Core asset developers
    • Product developers
  • New relationships with customers and suppliers.
  • Conformance to product line vision.

Activities KPA's

  • Certain skills are required to support the three activity areas above.
  • A practice area is a body of work or a collection of activities that an org. mast master to successfully carry out the essential work of a product line.
  • SW Engg KPA's to support Core Asset development activities and product development activities.
  • Technical Management KPA's and Org Mgmt KPA's to support management activities.

SE Practice Areas

  • Requirements Engineering
  • Architecture Definition
    • Consider aspects peculiar to product lines.
    • Must provide builtin mechanisms.
    • Systematic use of modifiability tactics - e.g. binding time, parametrise, localise changes.
  • Architecture Evaluation
  • Component Development
  • COTS Utilisation
  • Mining existing assets
  • System integration
  • Testing
  • Understanding relevant domains

Technical Mgmt Practice Areas

  • Process definition
  • Scoping
  • Technical planning
  • Technical risk management
  • Tool support
  • Config Mgmt
  • Make/buy/mine commission analysis.
    • Buying COTS maybe more expensive - but is already generic.
    • Cost of making might be more expensive for product line (wrt expectation of wide use)
  • Data collection, metrics and tracking.

Org mgmt practice areas

  • Building a business case
  • Market Analysis
  • Funding
  • Launching and institutionalising
  • Operations
  • Org planning
  • Org risk management
  • Customer interface mgmt
  • Developing an acquisition strategy
  • Structuring the organisation
  • Technology forecasting
  • Training

Product Line Patterns

  • They are process patterns rather than architectural or design.
  • Relate KPA's to specific activities.
  • Context - Org Situation
  • Problem - What part of a product line effort needs to be done ?
  • Solution - Grouping of practice areas. Relations among these practice areas.

What to build pattern

  • Which KPA's help an org to decide on the products that need to be in the product line.
  • Context: An org has decided to field a sw product line and knows the general product area for the set of products.
  • Problem: To determine what products should be included in the product line.
  • Solution : Determining what to build requires information related to the product area, technology and market. The business justification and the process for describing the set of products to be included in the product line.

WhatToBuildPattern.png

Factory Pattern

  • Puts all the various patterns together.

PLFactoryPattern.png

  • What to Build - determines products to be included in PL
  • Each Asset - provides individual core assets
  • Product Parts - provides the assets to form a product
  • Assembly Line - establishes product build capability
  • Product Builder - builds the products
  • Cold Start - prepares organisation for PL operation
  • In Motion - keeps PL organisation running
  • Monitor - keeps watch on the organisation