Pitfalls of software product development

1,568 views
1,513 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
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,568
On SlideShare
0
From Embeds
0
Number of Embeds
387
Actions
Shares
0
Downloads
28
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide









































  • 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

    ×