![Production
Communication [part 1]: Desired Intent
• All software is expressed
in code
• Each code adheres to
a syntax defined in a meta code
• The producer associates
a desired intent with software
http://commons.wikimedia.org/wiki/
File:Encoding_communication-1-.jpg](https://image.slidesharecdn.com/software-product-development-100515022214-phpapp02/85/Pitfalls-of-software-product-development-6-320.jpg)
![Consumption
Communication [part 2]: Semantics
• The semantics of software are determined
by the reactions of consumers, not by the producer
• The desired intent and the semantics
can only be aligned through
extensive instantiation (by producers)
and semantic processing (by consumers)
of example instances
• Definition: An instance is a set that contains one
and only one element at any given point in time
http://commons.wikimedia.org/wiki/
File:Encoding_communication-1-.jpg](https://image.slidesharecdn.com/software-product-development-100515022214-phpapp02/85/Pitfalls-of-software-product-development-7-320.jpg)
![Models
Species : DomesticAnimal
isAbstract : yes
dateOfBirth
Models are
software artefacts
that represent Species : Dog Species : Cat
isAbstract : no [2] isAbstract : no [2]
isPoliceDog
the desired intent [*] [*]
associated with a system
Dog : Jack Cat : Coco
{1/5/03, yes} {4/3/07}
in a human-friendly Dog : Susie
{1/2/00, no}
Cat : Peter
{10/9/98}
syntax](https://image.slidesharecdn.com/software-product-development-100515022214-phpapp02/85/Pitfalls-of-software-product-development-34-320.jpg)
Pitfalls of software product development
- 1. Software Product Development Pitfalls
- 2. Language Artefacts A language artefact is a container of information that • is created by a specific actor (human or a system) • is consumed by at least one actor (human or system) • represents a natural unit of work (for the creating and consuming actors) • may contain links to other language artefacts • has a state and a life-cycle http://commons.wikimedia.org/wiki/ File:Photo_with_histogram.JPG
- 3. Examples Language artefacts are non-hardware artefacts • information content of pheromones • information content of body language • live music • live speech • information content in traditional symbolic notations • program/diagram/hypertext/database content • information content of recorded sound/pictures/videos • information content of genetic material
- 4. Software Software is an arbitrary set of language artefacts
- 5. Today Software suffers from the same problems as http://commons.wikimedia.org/wiki/ way back File:Cloud_computing_icon.svg • when natural language evolved to enrich the exchange between humans • Increasingly the artefacts exchanged between humans are neither hardware http://commons.wikimedia.org/wiki/ File:Discussion.jpg nor natural language (encoded in speech or symbolic notation) • All language artefacts share the probems of natural language: unanticipated interpretations, etc.
- 6. Production Communication [part 1]: Desired Intent • All software is expressed in code • Each code adheres to a syntax defined in a meta code • The producer associates a desired intent with software http://commons.wikimedia.org/wiki/ File:Encoding_communication-1-.jpg
- 7. Consumption Communication [part 2]: Semantics • The semantics of software are determined by the reactions of consumers, not by the producer • The desired intent and the semantics can only be aligned through extensive instantiation (by producers) and semantic processing (by consumers) of example instances • Definition: An instance is a set that contains one and only one element at any given point in time http://commons.wikimedia.org/wiki/ File:Encoding_communication-1-.jpg
- 8. Communication? Golf f nce o Concept rs Concept insta of ca is an ABC instance 123 is an ABC 1 23 Instance Instance Golf engineer sales person
- 9. Validation Concept Concept instantiate ABC 1 23 Instance Instances engineer sales person
- 11. The Software Buyer Knows there’s a problem http://commons.wikimedia.org/wiki/ File:JonWoodApril2007Texas.jpg
- 12. The Software Buyer Knows there’s a problem http://commons.wikimedia.org/wiki/ File:JonWoodApril2007Texas.jpg but can’t visualize the software solution to the problem
- 13. Value of Software http://commons.wikimedia.org/wiki/ is hard to File:Cloud_computing_icon.svg communicate • It’s not tangible • It’s not raw information • Customers suspect hidden costs
- 14. Help the Buyer to visualize the software • The buyer must recognise your product as the desired solution within 5 to 10 minutes • The buyer is easily confused by details and unfamiliar jargon • The buyer extrapolates from first impressions: installation and configuration
- 15. First Impressions Shock of Configuration & Customization • Configurability has either been grafted on at the last minute or is the result of unsubstantiated speculation by the software team • No one thought about the importance of decision binding times • No one thought about the level of abstraction at which users typically articulate configuration needs • Modularity of configuration artefacts is insufficient • Functionality such as consistency checks and change impact analysis is either lacking or poor
- 16. First Impressions Shock of Configuration & Customization • Configurability has either been grafted on at the last minute or is the result of unsubstantiated speculation by the software team http://commons.wikimedia.org/wiki/ File:A-380_Cockpit.jpg • No one thought about the importance of decision binding times • No one thought about the level of abstraction at which users typically articulate configuration needs • Modularity of configuration artefacts is insufficient http://commons.wikimedia.org/wiki/ • Functionality such as consistency checks and change File:RecipeBook_XML_Example.svg impact analysis is either lacking or poor
- 17. First Impressions Shock of Configuration & Customization http://commons.wikimedia.org/wiki/ • Configurability has either been grafted on at the last File:Portrait_Dearnell_portrait.JPG minute or is the result of unsubstantiated speculation by the software team • No one thought about the importance of decision binding times • No one thought about the level of abstraction at which users typically articulate configuration needs • Modularity of configuration artefacts is insufficient http://commons.wikimedia.org/wiki/ • Functionality such as consistency checks and change File:Portrait_gilles.jpg impact analysis is either lacking or poor
- 18. First Impressions Shock of Configuration & Customization • Configurability has either been grafted on at the last minute or is the result of unsubstantiated speculation Golf by the software team • No one thought about the importance of decision binding times • No one thought about the level of abstraction at which users typically articulate configuration needs • Modularity of configuration artefacts is insufficient ABC 123 • Functionality such as consistency checks and change impact analysis is either lacking or poor
- 19. First Impressions Shock of Configuration & Customization • Configurability has either been grafted on at the last minute or is the result of unsubstantiated speculation by the software team • No one thought about the importance of decision binding times • No one thought about the level of abstraction at which users typically articulate configuration needs • Modularity of configuration artefacts is insufficient • Functionality such as consistency checks and change impact analysis is either lacking or poor
- 20. First Impressions Shock of Configuration & Customization • Configurability has either been grafted on at the last minute or is the result of unsubstantiated speculation by the software team • No one thought about the importance of decision binding times • No one thought about the level of abstraction at which users typically articulate configuration needs • Modularity of configuration artefacts is insufficient • Functionality such as consistency checks and change http://commons.wikimedia.org/wiki/ File:Ann_dependency_graph.png impact analysis is either lacking or poor
- 21. Market Assessment (Example) Tier 1 2 3 Length of Sales Cycle +++ ++ + Simple Web Based Marketing + ++ +++ Configurability Expectations +++ ++ + # of Potential Customers + ++ +++ Total Value ++ +++ + Tier-1 market is not always the biggest
- 23. Economics of Software Software products can get killed by • Long time to market • Poor user interface • Configuration and customisation costs • Maintenance & developmemt costs of new features The last item eventually kills most products
- 24. Economics of Software Software products can get killed by • Long time to market • Poor user interface • Configuration and customisation costs • Maintenance & developmemt costs of new features The last item eventually kills most products
- 25. Economics of Software Software products can get killed by • Long time to market • Poor user interface • Configuration and customisation costs • Maintenance & developmemt costs of new features The last item eventually kills most products
- 26. Economics of Software Software products can get killed by • Long time to market • Poor user interface • Configuration and customisation costs • Maintenance & developmemt costs of new features The last item eventually kills most products
- 27. Economics of Software Software products can get killed by • Long time to market • Poor user interface • Configuration and customisation costs • Maintenance & developmemt costs of new features The last item eventually kills most products
- 28. Economics of Software Software products can get killed by • Long time to market • Poor user interface • Configuration and customisation costs • Maintenance & developmemt costs of new features The last item eventually kills most products!
- 29. Domain Analysis Analysis of variabilities & commonalities • Dimensions of variability (e.g. legislation, interface types, bus. units) • Binding times & asscociated roles • Elements within each dimension of variability • Effects of each variability in terms of product features • Market value of each dimension of variability Ask customers/prospects, don’t speculate
- 30. Product Family Development Domain Engineering Timeboxed Iterations Define application family and develop production facility Application Engineering Environment Modelling Language Definitions +Tools (Editors, Generators, Interpreters, Transformations) +Application Engineering Process Application Engineering Timeboxed Iterations Produce family members Applications Applications Applications Applications
- 31. Release Management Domain Engineering Timeboxed Iterations Define application family and develop production facility AE Environment R1.0 AE Environment R1.1 AE Environment R1.2 AE Environment R2.0 Feedback Feedback Feedback Application Engineering Timeboxed Iterations Produce family members R1.0 A,B,C, ... Apps R1.1 A,B,C, ... Apps R1.2 A,B,C, ... Apps
- 32. Scalability http://commons.wikimedia.org/wiki/ File:Modular_origami.jpg Modules preserve simplicity
- 33. Pain Point http://commons.wikimedia.org/wiki/ File:Ann_dependency_graph.png number of semantic links between modules Dependency graphs must also be modularised
- 34. Models Species : DomesticAnimal isAbstract : yes dateOfBirth Models are software artefacts that represent Species : Dog Species : Cat isAbstract : no [2] isAbstract : no [2] isPoliceDog the desired intent [*] [*] associated with a system Dog : Jack Cat : Coco {1/5/03, yes} {4/3/07} in a human-friendly Dog : Susie {1/2/00, no} Cat : Peter {10/9/98} syntax
- 35. Modelling is about Clarity All models are code • a system of symbols used for • identification • classification in the sense of grouping • a system of signals used to send messages • a set of conventions governing behaviour Modelling is meta coding to improve clarity of code
- 36. Modelling Language Design http://commons.wikimedia.org/wiki/File:Human_Cognition.jpg Modelling language design is a balancing act between simplicity and not compromising the desired intent • Focus is on the view point of human cognitive ability • Modelling languages often make use of multiple syntax elements (visual containers, visual symbols, text, mathematical expressions) • Syntax elements are either borrowed from existing language artefacts, or are designed and incrementally refined in close collaboration with the user community
- 37. Interpretation <=> airplane or aircraft ? <=> commercial aircraft ? <=> ship or boat ? <=> ferry or cruise ship ? <=> car ferry ? <=> paddler or boat ? Observation: It works 80% of the time
- 38. Less Speculation ... and much more validation • Guessing 80% of what customers need is not good enough • Get customers involved in product design • Instantiate models to obtain rapid feedback • Act on feedback - within weeks, not months (c) copyright 2006, Blender Foundation / Netherlands • Validate working software Media Art Institute / www.elephantsdream.org with selected customers on a monthly basis
- 39. Domain Analysis Cheat Sheet
- 40. Language design cheat sheet 40 Breaking down complexity into manageable modules
- 41. More Information The Role of Artefacts tiny.cc/artefacts From Muddling to Modelling tiny.cc/muddleToModel Model Oriented Domain Analysis tiny.cc/domainanalysis Multi-Level Modelling tiny.cc/gmodel tiny.cc/sematpos_jbe, Perspective on SEMAT tiny.cc/sematslides_jbe Denotational Semantics tiny.cc/densem Thank you Jorn Bettin jbe @ sofismo.ch Software is Models www.sofismo.ch