Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pitfalls of software product development

1,780 views

Published on

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.

Published in: Business
  • Be the first to comment

Pitfalls of software product development

  1. 1. Software Product Development Pitfalls
  2. 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. 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. 4. Software Software is an arbitrary set of language artefacts
  5. 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. 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. 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. 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. 9. Validation Concept Concept instantiate ABC 1 23 Instance Instances engineer sales person
  10. 10. The Software Buyer
  11. 11. The Software Buyer Knows there’s a problem http://commons.wikimedia.org/wiki/ File:JonWoodApril2007Texas.jpg
  12. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. Economics of Software
  23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 32. Scalability http://commons.wikimedia.org/wiki/ File:Modular_origami.jpg Modules preserve simplicity
  33. 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. 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. 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. 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. 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. 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. 39. Domain Analysis Cheat Sheet
  40. 40. Language design cheat sheet 40 Breaking down complexity into manageable modules
  41. 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

×