pitfalls of software product development
Post on 29-Jan-2018
1.673 Views
Preview:
TRANSCRIPT
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
top related