Software Product Lines

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