Difference between revisions of "Software Product Lines"
From Suhrid.net Wiki
Jump to navigationJump to searchLine 36: | Line 36: | ||
* Just a set of technical standards - constraining choices without an arch. based strategy. | * Just a set of technical standards - constraining choices without an arch. based strategy. | ||
− | = Benefits of product line = | + | = Benefits and risks of product line = |
+ | |||
+ | == Benefits == | ||
* Decreased cost | * Decreased cost | ||
Line 44: | Line 46: | ||
* Improved quality | * Improved quality | ||
* Ability to move into new markets | * 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 ? |
Revision as of 09:36, 12 April 2012
Contents
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 ?