software product lines
Post on 14-Dec-2014
256 Views
Preview:
DESCRIPTION
TRANSCRIPT
jason@miles.no @miles_no
software product lines
aka:
product line architecture
product family engineering
...
jason@miles.no @miles_no
why
jason@miles.no @miles_no
your problem to solve:
design the solution architecture for standardised case
management for all employment and social security
benefts in Norway (26 → 40 benefts)
Enterprise Architect: “They all follow the same
business process!”
Domain Expert: “They are all diferent!”
Case Handlers: “They all have to look for the same to
us!”
jason@miles.no @miles_no
“On the design and
development of
Program Families”
- Parnas, 1976
Alternatives:
- Reference Architecture
- One-size-fts-all
- Software Product Line
jason@miles.no @miles_no
core problem:
must understand the nature of variability in your
problem domain
Structural (Essential)
inherent in the problem domain- business wants to offer a set of products- product differentiation is a competitive advantage
Incidental(Accidental)
purely technical- technical debt- different development teams- etc
jason@miles.no @miles_no
alternative 1: reference architecture
common logical architecture for all products
separate product instances in production
reuse of knowledge
opportunistic reuse of components
no explicit variation management
SU
SP
FP
jason@miles.no @miles_no
alternative 2: one-size-fits-all
one physical architecture for all products
single product instance in production
complex variation management
significant reuse of components
difficult to deal with variation in quality requirements
regression testing for all products for all changes
SU SP FP
jason@miles.no @miles_no
alternative 3: software product lines
common logical architecture for all products
separate product instances in production
reuse of knowledge
explicit variation management: functional and quality requirements
explicit reuse of components
requires more architecture investment
FP
SU
Felles
jason@miles.no @miles_no
jason@miles.no @miles_no
what
jason@miles.no @miles_no
jason@miles.no @miles_no
jason@miles.no @miles_no
jason@miles.no @miles_no
Domain Engineering
Application Engineering
jason@miles.no @miles_no
jason@miles.no @miles_no
jason@miles.no @miles_no
how
jason@miles.no @miles_no
how
jason@miles.no @miles_no
how
jason@miles.no @miles_no
BDUF or agile software product lines?
jason@miles.no @miles_no
how
jason@miles.no @miles_no
variation points in the architecture
For our case management domain:
variation in process
variation in domain model
variation in presentation
variation in legislation
variation in integration with external actors
jason@miles.no @miles_no
variation guide
. doma in mode l . rule templates
. java component integration . service level integration
jason@miles.no @miles_no
. selling the business case
. getting product owner(s) / domain experts to think
across products
. project organisation structure for common
components and product development
. how do you defne user stories and other
requirements?
. how much upfront design?
. SPL for enterprisey software rather than
embedded systems
Jones, Lawrence G ., and Linda M . Northrop. 2010. “Clearing the Way for Software Product Line Success.” IEEE Software 27 (3) (June).
jason@miles.no @miles_no
summary
. is variation inherent to the business domain?
. are there enough products to justify payof with a
product line approach?
. analyse the variation
. design the architecture wrt commonalities and
variations
. develop a variation guide for combining common
assets and product-specifc variants
. don't forget the non-architecture challenges
jason@miles.no @miles_no
more info
http://www.sei.cmu.edu/productlines/tools/framework/
● slides and images liberally stolen reused from
http://www.sei.cmu.edu/library/assets/spl-essentials.pdf
http://splc.net
jason@miles.no @miles_no
software product lines
aka:product line architecture
product family engineering
...
* will talk about product lines* illustrate concepts with the modernisation of case management at NAV
jason@miles.no @miles_no
why
* start with the why and compare it to other techniques* then look at what is a SPL * and then how we have been going about it
jason@miles.no @miles_no
your problem to solve:
design the solution architecture for standardised case
management for all employment and social security
benefts in Norway (26 → 40 benefts)
Enterprise Architect: “They all follow the same
business process!”
Domain Expert: “They are all diferent!”
Case Handlers: “They all have to look for the same to
us!”
* how do you design the architecture for a while set of solutions?* all the solutions have many things in common but there is considerable variability* nobody is too sure what that variability is, nor what can be standardised
jason@miles.no @miles_no
“On the design and
development of
Program Families”
- Parnas, 1976
Alternatives:
- Reference Architecture
- One-size-fts-all
- Software Product Line
* lots of research and industry experience on dealing with variability in software architecture* long history of dealing with Product Families* variations in functionality* variations in support for quality requirements* all that background shows three main alternatives
jason@miles.no @miles_no
core problem:
must understand the nature of variability in your
problem domain
Structural (Essential)
inherent in the problem domain- business wants to offer a set of products- product differentiation is a competitive advantage
Incidental(Accidental)
purely technical- technical debt- different development teams- etc
* before you can analyse which alternative is relevant for you, you need to understand the nature of variation* Is it Essential or Accidental?
jason@miles.no @miles_no
alternative 1: reference architecture
common logical architecture for all products
separate product instances in production
reuse of knowledge
opportunistic reuse of components
no explicit variation management
SU
SP
FP
*
jason@miles.no @miles_no
alternative 2: one-size-fits-all
one physical architecture for all products
single product instance in production
complex variation management
significant reuse of components
difficult to deal with variation in quality requirements
regression testing for all products for all changes
SU SP FP
*
jason@miles.no @miles_no
alternative 3: software product lines
common logical architecture for all products
separate product instances in production
reuse of knowledge
explicit variation management: functional and quality requirements
explicit reuse of components
requires more architecture investment
FP
SU
Felles
*
jason@miles.no @miles_no
* summary.* notice when and how you explicitly handle variation (or not at all)
jason@miles.no @miles_no
what
* all about product lines in general*
jason@miles.no @miles_no
* all about product lines in general* architecture astronaut definition but there are actually many that use it successfully in practice** Nokia** GM car software** etc
jason@miles.no @miles_no
* variation in software products directly linked to business case that can be build a business model around products.* easy in the embedded domain but not as common in the enterprise domain
jason@miles.no @miles_no
* long term goal is to achieve this* not necessarily how you start* can't forget the management and organisation
jason@miles.no @miles_no
Domain Engineering
Application Engineering
* core asset development = domain engineering* product development based on assets = application engineering
jason@miles.no @miles_no
* not just component reuse* all the artefacts in the dev lifecycle
jason@miles.no @miles_no
* requires architecture investment and you wont get the payback on the first system* There are alternatives. Ex: huge developer base in india
jason@miles.no @miles_no
how
* variation analysis* variation points in the architecture* variation guide to describe how to deal with the variations in technology
jason@miles.no @miles_no
how
* Need to consider the approach from two dimensions:** product, process and organisation** setting the context, getting started, working long-term
jason@miles.no @miles_no
how
* example activities you can do in all these areas.** we looked at each of these to understand the ones that were the most relevant and pressing
jason@miles.no @miles_no
BDUF or agile software product lines?
* Do you have to do all this upfront?* we started reactive but are moving to more incremental.** focus on analysis on variation rather than building components
jason@miles.no @miles_no
how
* variation analysis* variation points in the architecture* variation guide to describe how to deal with the variations in technology
jason@miles.no @miles_no
variation points in the architecture
For our case management domain:
variation in process
variation in domain model
variation in presentation
variation in legislation
variation in integration with external actors
* domain analysis to find the commonalities and variations* feature models are a popular technique* what we have been focussing on in case management
jason@miles.no @miles_no
variation guide
. domain model . rule templates
. java component integration . service level integration
* how do you solve each of the variation point types in technology* some variation will disappear by simply analysing it with the business team and they realise that its unnecessary - harmonisation* separate bounded contexts for the legislation domain and user facts domains
most facts become value objects that can be handled with collections
domain model structure is less dependent of variation
soft-schema document based persistence * sprint contexts for java component integration* SOAP service integration handled with WS-Addressing because of the cloud infrastructure
jason@miles.no @miles_no
. selling the business case
. getting product owner(s) / domain experts to think
across products
. project organisation structure for common
components and product development
. how do you defne user stories and other
requirements?
. how much upfront design?
. SPL for enterprisey software rather than
embedded systems
Jones, Lawrence G ., and L inda M . Northrop. 2010. “Clearing the Way for Software Product Line Success.” IEEE Software 27 (3) (June).
* many known pitfalls which are good to keep in mind* we've had to deal with the following already
jason@miles.no @miles_no
summary
. is variation inherent to the business domain?
. are there enough products to justify payof with a
product line approach?
. analyse the variation
. design the architecture wrt commonalities and
variations
. develop a variation guide for combining common
assets and product-specifc variants
. don't forget the non-architecture challenges
* When is it relevant?* How do you go about it?
jason@miles.no @miles_no
more info
http://www.se i.cmu.edu/productlines/too ls/framework/
● slides and images liberally stolen reused from
http://www.sei.cmu.edu/library/assets/spl-essentia ls.pdf
http://splc.net
* the framework has all the basic info you need to get started* Product line conference exist and the website has a nice set of case studies (HoF)
top related