Software product development teams – and people in general - commonly over-estimate their ability to convey information in documents, diagrams, and in discussions. To make matters worse, they typically have too much faith in the validity of their personal mental models to frame the problems that need to be solved. As a result, misinterpretations often remain undetected for months, milestones are missed, and deliverables don’t meet expectations. Many failures are avoidable by recognising the role of customers - and of communication and collaboration - in 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

10. The Software Buyer

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

22. Economics of Software

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