Your SlideShare is downloading. ×
0
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Software Product Lines
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Software Product Lines

436

Published on

Presentation about product line architecture to the Oslo Software Architecture meetup

Presentation about product line architecture to the Oslo Software Architecture meetup

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
436
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. software product lines aka: product line architecture product family engineering ... jason@miles.no @miles_no
  • 2. why jason@miles.no @miles_no
  • 3. 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
  • 4. “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
  • 5. core problem: must understand the nature of variability in your problem domain Structural (Essential) Incidental (Accidental) jason@miles.no inherent in the problem domain - business wants to offer a set of products - product differentiation is a competitive advantage purely technical - technical debt - different development teams - etc @miles_no
  • 6. alternative 1: reference architecture SU SP FP common logical architecture for all products separate product instances in production reuse of knowledge opportunistic reuse of components no explicit variation management jason@miles.no @miles_no
  • 7. alternative 2: one-size-fits-all SU SP FP 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 jason@miles.no @miles_no
  • 8. alternative 3: software product lines FP SU Felles 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 jason@miles.no @miles_no
  • 9. jason@miles.no @miles_no
  • 10. what jason@miles.no @miles_no
  • 11. jason@miles.no @miles_no
  • 12. jason@miles.no @miles_no
  • 13. jason@miles.no @miles_no
  • 14. Domain Engineering Application Engineering jason@miles.no @miles_no
  • 15. jason@miles.no @miles_no
  • 16. jason@miles.no @miles_no
  • 17. how jason@miles.no @miles_no
  • 18. how jason@miles.no @miles_no
  • 19. how jason@miles.no @miles_no
  • 20. BDUF or agile software product lines? jason@miles.no @miles_no
  • 21. how jason@miles.no @miles_no
  • 22. 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
  • 23. variation guide . domain model . rule templates . java component integration . service level integration jason@miles.no @miles_no
  • 24. Jones, Lawrence G., and Linda M. Northrop. 2010. “Clearing the Way for Software Product Line Success.” IEEE Software 27 (3) (June). . 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 jason@miles.no @miles_no
  • 25. 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
  • 26. more info http://splc.net 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 jason@miles.no @miles_no
  • 27. software product lines aka: product line architecture product family engineering ... jason@miles.no @miles_no * will talk about product lines * illustrate concepts with the modernisation of case management at NAV
  • 28. why jason@miles.no @miles_no * 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
  • 29. 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 * 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
  • 30. “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 * 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
  • 31. core problem: must understand the nature of variability in your problem domain Structural (Essential) Incidental (Accidental) jason@miles.no inherent in the problem domain - business wants to offer a set of products - product differentiation is a competitive advantage purely technical - technical debt - different development teams - etc @miles_no * before you can analyse which alternative is relevant for you, you need to understand the nature of variation * Is it Essential or Accidental?
  • 32. alternative 1: reference architecture SU SP FP common logical architecture for all products separate product instances in production reuse of knowledge opportunistic reuse of components no explicit variation management jason@miles.no * @miles_no
  • 33. alternative 2: one-size-fits-all SU SP FP 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 jason@miles.no * @miles_no
  • 34. alternative 3: software product lines FP SU Felles 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 jason@miles.no * @miles_no
  • 35. jason@miles.no * summary. * notice when and how you explicitly handle variation (or not at all) @miles_no
  • 36. what jason@miles.no * all about product lines in general * @miles_no
  • 37. 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
  • 38. 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
  • 39. jason@miles.no @miles_no * long term goal is to achieve this * not necessarily how you start * can't forget the management and organisation
  • 40. Domain Engineering Application Engineering jason@miles.no @miles_no * core asset development = domain engineering * product development based on assets = application engineering
  • 41. jason@miles.no * not just component reuse * all the artefacts in the dev lifecycle @miles_no
  • 42. 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
  • 43. how jason@miles.no @miles_no * variation analysis * variation points in the architecture * variation guide to describe how to deal with the variations in technology
  • 44. how jason@miles.no @miles_no * Need to consider the approach from two dimensions: ** product, process and organisation ** setting the context, getting started, working longterm
  • 45. how jason@miles.no @miles_no * 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
  • 46. BDUF or agile software product lines? jason@miles.no * 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 @miles_no
  • 47. how jason@miles.no @miles_no * variation analysis * variation points in the architecture * variation guide to describe how to deal with the variations in technology
  • 48. 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 * domain analysis to find the commonalities and variations * feature models are a popular technique * what we have been focussing on in case management
  • 49. variation guide . domain model . rule templates . java component integration . service level integration jason@miles.no @miles_no * 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 WSAddressing because of the cloud infrastructure
  • 50. Jones, Lawrence G., and Linda M. Northrop. 2010. “Clearing the Way for Software Product Line Success.” IEEE Software 27 (3) (June). . 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 jason@miles.no @miles_no * many known pitfalls which are good to keep in mind * we've had to deal with the following already
  • 51. 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 * When is it relevant? * How do you go about it? @miles_no
  • 52. more info http://splc.net 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 jason@miles.no @miles_no * 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)

×