Software Product Development

Pitfalls

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

Language Artefacts

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

Software

Software is an arbitrary set of language artefacts

http://commons.wikimedia.org/wiki/File:Discussion.jpg

Software suffers from the same problems as way back• when natural language evolved to

enrich the exchange between humans

• Increasingly the artefacts exchanged between humans are neither hardware nor natural language (encoded in speech or symbolic notation)

• All language artefacts share the probems of natural language: unanticipated interpretations, etc.

Today

http://commons.wikimedia.org/wiki/File:Cloud_computing_icon.svg

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

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

Communication?

sales personengineer

Gol

f is

an in

stan

ce o

f car

sA

BC

123

is a

n in

stan

ce o

f Gol

f

ABC 123

Concept

Instance

Concept

Instance

sales personengineer

instantiate

Validation

ABC 123

Concept

Instance

Concept

Instances

The Software Buyer

The Software BuyerKnows there’s a problem

http://commons.wikimedia.org/wiki/File:JonWoodApril2007Texas.jpg

The Software BuyerKnows there’s a problem

but can’t visualize the software solution to the problem

http://commons.wikimedia.org/wiki/File:JonWoodApril2007Texas.jpg

is hard to communicate• It’s not tangible

• It’s not raw information

• Customers suspect hidden costs

Value of Software

http://commons.wikimedia.org/wiki/File:Cloud_computing_icon.svg

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

Help the Buyer

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

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

First Impressions

http://commons.wikimedia.org/wiki/File:A-380_Cockpit.jpg

http://commons.wikimedia.org/wiki/File:RecipeBook_XML_Example.svg

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

First Impressions

http://commons.wikimedia.org/wiki/File:Portrait_gilles.jpg

http://commons.wikimedia.org/wiki/File:Portrait_Dearnell_portrait.JPG

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

First Impressions

Golf

ABC 123

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

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

First Impressions

http://commons.wikimedia.org/wiki/File:Ann_dependency_graph.png

Market Assessment (Example)

Tier 1 2 3Length of Sales Cycle +++ ++ +

Simple Web Based Marketing + ++ +++Configurability Expectations +++ ++ +

# of Potential Customers + ++ +++Total Value ++ +++ +

Tier-1 market is not always the biggest

Economics of Software

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

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

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

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

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

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!

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

Product Family Development

Timeboxed Iterations

Timeboxed IterationsDomain Engineering

Define application family and develop production facility

Application EngineeringProduce family members

Application Engineering EnvironmentModelling Language Definitions

+Tools (Editors, Generators, Interpreters, Transformations)+Application Engineering Process

ApplicationsApplicationsApplicationsApplications

Release Management

Timeboxed Iterations

Timeboxed IterationsDomain Engineering

Define application family and develop production facility

Application EngineeringProduce family members

AE Environm

ent R1.0

AE Environm

ent R1.1

AE Environm

ent R1.2

AE Environm

ent R2.0

Feed

back

Feed

back

Feed

back

Apps

A,B,C

, ...R

1.0

Apps

A,B,C

, ...R

1.1

Apps

A,B,C

, ...R

1.2

Scalability

Modules preserve simplicity

http://commons.wikimedia.org/wiki/File:Modular_origami.jpg

Pain Point

Dependency graphs must also be modularised

number of semantic links

between modules

http://commons.wikimedia.org/wiki/File:Ann_dependency_graph.png

Models

Models are software artefacts that represent

the desired intent associated with a system

in a human-friendly syntax

Species : DomesticAnimal

isAbstract : yesdateOfBirth

Species : Dog

isAbstract : noisPoliceDog

Species : Cat

isAbstract : no

Dog : Jack{1/5/03, yes}

Dog : Susie{1/2/00, no}

Cat : Coco{4/3/07}

Cat : Peter{10/9/98}

[*]

[2]

[*]

[2]

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

Modelling Language Design

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

http://commons.wikimedia.org/wiki/File:Human_Cognition.jpg

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

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

• Validate working software with selected customers on a monthly basis

(c) copyright 2006, Blender Foundation / Netherlands Media Art Institute / www.elephantsdream.org

Domain AnalysisCheat Sheet

Breaking down complexity into manageable modules

Language design cheat sheet

40

Thank youJorn Bettin

Software is Models

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

Perspective on SEMAT tiny.cc/sematpos_jbe, tiny.cc/sematslides_jbe

Denotational Semantics tiny.cc/densem

More Information

jbe @ sofismo.ch www.sofismo.ch