1 / 42

Methods of Software Development Versioning

Methods of Software Development Versioning. Chris Scaffidi. Questions?. Was the reading clear? You can talk intelligently about the terms… “factor” and “actor” “production function” and “utility function” “quality attribute”, “metric”, and “validity” “qualitative” and “quantitative”

lonato
Download Presentation

Methods of Software Development Versioning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Methods of Software DevelopmentVersioning Chris Scaffidi

  2. Questions? Was the reading clear? You can talk intelligently about the terms… • “factor” and “actor” • “production function” and “utility function” • “quality attribute”, “metric”, and “validity” • “qualitative” and “quantitative” • “ATAM” and “COCOMO II” • “process” and “CMM”

  3. Overview • Why version? • Pricing is a challenge • Differentiation is one key • How to version? • Identify important attributes • Design to optimize on those attributes • Implement to achieve the design

  4. Pricing is a challenge What is this curve? Why Version?

  5. Price Quantity Price versus quantity A demand curve is a utility curve between product and money. Why Version? > Pricing is a challenge

  6. Price Quantity Price versus quantity Why does it start high and then slope down? Why Version? > Pricing is a challenge

  7. Price Quantity Value versus quantity Only a few people find enough value (utility) in the product to justify paying higher prices. But lots of people find enough value in the product to justify paying lower prices. Why Version? > Pricing is a challenge

  8. Price Production Cost Per Unit Quantity Maximizing profit Challenge: Maximize your profit by picking the best price to charge. Why Version? > Pricing is a challenge

  9. Differentiation is one key • The challenge is complicated by competition. • You compete with other vendors. • You compete with yourself! • One tractable solution is differentiation. • Versions can vary in functionality. • Versions can vary in price. Why Version?

  10. Price Production Cost Per Unit Quantity Scenario #1: One version • Make one version. • Pick a price. • That tells quantity sold. • Profit is shown in shaded box. • (Minus flat costs, of course.) Why Version? > Differentiation is one key

  11. Price Production Cost Per Unit Quantity Scenario #2: Two versions • Make two versions: • Different price & functionality. • This entices a few more buyers. • You get a little extra profit. • Danger: Self-Competition Why Version? > Differentiation is one key

  12. Price Production Cost Per Unit Quantity Scenario #2: Two versions This is what happens when you compete with yourself too much. Danger: Self-Competition Why Version? > Differentiation is one key

  13. Price Production Cost Per Unit Quantity Scenario #3: Several versions If two is good, more is better? Why Version? > Differentiation is one key

  14. Price Production Cost Per Unit Quantity Scenario #4: Infinitely many versions “1st Degree Price Discrimination” Perfectly personalized products Perfectly matches the curve Maximizes the profit? What’s wrong with this picture? Why Version? > Differentiation is one key

  15. 1st vs 2nd degree price discrimination “1st degree price discrimination” = Personalized pricing • Fits the demand curve closely • May raise production costs a lot • May be impossible with some products “2nd degree price discrimination” = Versioning (or volume discounts) • Approximates the demand curve • May raise production costs Why Version? > Differentiation is one key

  16. 3rd degree price discrimination “3rd degree price discrimination” = Group pricing • Targets each version at a group of buyers • Can simplify design and marketing process • Can boost network effects (value) • Most useful when buyers fall into clean categories Price discrimination means matching good prices to your product’s differentiated versions. Why Version? > Differentiation is one key

  17. How to Version? • Why version? • Pricing is a challenge • Differentiation is one key • How to version? • Identify important attributes • Design to optimize on those attributes • Implement to achieve the design You are here How to Version?

  18. Utility curves differ Versions are differentiated (i.e.: their attributes vary). You want your versions to have varied utility (why?) The key: know thy customers’ utility function If you know how utility depends on attributes, then you know which attributes should vary by version. How to Version? > Identify important attributes

  19. Example: Utility of availability Utility in e-Commerce as a function of availability B. Boehm, et al. “The ROI of Software Dependability: The iDAVE Model”, IEEE Software, May/June 2004. How to Version? > Identify important attributes

  20. Example: Utility of timeliness NASA Mission Control Software Real-Time Control Weather Prediction B. Boehm. HDCP Review Talk at CMU. Oct 15, 2004. How to Version? > Identify important attributes

  21. The wide-wide world of attributes Utility can be a function of many attributes… • Functional attributes • Formats supported • Precision supported • Searches supported • Calculations supported • Views / interfaces provided • Image resolution How to Version? > Identify important attributes

  22. The wide-wide world of attributes Utility can be a function of many attributes… • Functional attributes • Extra-functional attributes • Timeliness to market • Timeliness of the software’s outputs (≈ performance) • Availability of technical support • Availability of the software itself • Maintainability • Flexibility & extensibility • Platforms supported & portability How to Version? > Identify important attributes

  23. The wide-wide world of attributes Utility can be a function of many attributes… • Functional attributes • Extra-functional attributes … and also a function of whether that irritating “Please Register this Software”box keeps popping up in demoware versions! How to Version? > Identify important attributes

  24. Example: e-Commerce platform Example: Suppose we’re designing an e-Commerce platform. Our target market is online booksellers. • How should versions vary by availability? • What other attributes will probably affect utility? How to Version?

  25. Design to optimize on those attributes Once you know which attributes to vary, the next step is knowing how much you want in versions. This is a Qualitative-to-Quantitative thought process. There are many approaches to making this transition. Examples: • ATAM • COCOMO II • Cobb-Douglas How to Version?

  26. ATAM utility tree Build a utility tree 1. Identify attributes 2. Operationalize 3. Assign priorities 4. Design Repeat until everybody is adequately joyful. How to Version? > Design to optimize on those attributes

  27. COCOMO II PM = M * Size S PM = person-months to build (≈ flat building cost) Size = software size in KSLOC S = 0.91 + 0.01 * Σ si si = scale factor i, describes your company How to Version? > Design to optimize on those attributes

  28. COCOMO II PM = M * Size S PM = person-months to build (≈ flat building cost) Size = software size in KSLOC S = 0.91 + 0.01 * Σ si si = scale factor i, describes your company M = 2.94 *  mi mi = effort modifier i, describes your company and also attributes of the version How to Version? > Design to optimize on those attributes

  29. COCOMO II PM = M * Size S PM = person-months to build (≈ flat building cost) Size = software size in KSLOC S = 0.91 + 0.01 * Σ si si = scale factor i, describes your company M = 2.94 *  mi mi = effort modifier i, describes your company and also attributes of the version How to Version? > Design to optimize on those attributes

  30. Cobb-Douglas optimization Production functions can be approximated as Z = k *  Yi Z = amount of output generated k = constant Y = amount of input required i = elasticity of input i (0.0 ≤ i ≤ 1.0) How to Version? > Design to optimize on those attributes

  31. Cobb-Douglas optimization Production is a suitable approximation for utility. You can maximize Z, subject to constraints. How to Version? > Design to optimize on those attributes

  32. Cobb-Douglas optimization Back to the book-ordering e-Commerce platform. We have a central web server plus a failover cluster. Some handy over-simplifications: • Each search tool costs 64MB RAM + 1 cluster server • Each “9” costs 10MB + 2 cluster servers (e.g.: 99.999%=5) • Total memory cannot exceed 2048MB RAM • Our hosting facility provides 15 failover cluster servers How to Version? > Design to optimize on those attributes

  33. Cobb-Douglas optimization Our buddies in marketing and operations tell us that Z = $500 * T0.2 * A0.1 Z = sales produced per month, in dollars T = number of search tools (elasticity = 0.2) A = availability, in “9”s (elasticity = 0.1) Our constraints were 64*T + 10*A ≤ 2048 1*T + 2*A ≤ 15 How to Version? > Design to optimize on those attributes

  34. Cobb-Douglas optimization Take the logarithm of both sides. Maximize (ln Z) = 0.2*(ln T) + 0.1*(ln A) + ln $500 Subject to 64*T + 10*A ≤ 2048 1*T + 2*A ≤ 15 Look familiar? How to Version? > Design to optimize on those attributes

  35. Implement to achieve the design Good job so far: • You identified the important attributes. • You figured out how much of each attribute you should put into each version. One step left: • Implement to actually deliver the desired quality attributes in the desired quantities. How to Version?

  36. Metrics and CMM • Metrics • For measuring operationalizations of attributes • Can be used to evaluate designs or code • Ask Ipek for long version of “Digest” for more examples How to Version? > Implement to achieve the design

  37. Metrics and CMM • Metrics • For measuring operationalizations of attributes • Can be used to evaluate designs or code • Ask Ipek for long version of “Digest” for more examples • CMM • Level 1: Chaotic and ad-hoc • Level 2: Repeatable process • Level 3: Documented process • Level 4: Metrics in use • Level 5: Optimization underway How to Version? > Implement to achieve the design

  38. Value-subtracted versions “In many cases, in fact, production of the low-quality version incurs additional costs.” -- C. Shapiro, H. Varian. “Information Rules”, Harvard Business School Press, 1999, p. 63. How to Version? > Implement to achieve the design

  39. Value-subtracted versions “In many cases, in fact, production of the low-quality version incurs additional costs.” “With information you usually produce the high-quality version first, and then subtract value from it to get to the low-quality version.” C. Shapiro, H. Varian. “Information Rules”, Harvard Business School Press, 1999, p. 63. How to Version? > Implement to achieve the design

  40. Fill in the gaps • What else is there? • Complements • You don’t have to build it all at once! • Build a version here and another there. • Build systems that complement some or all versions. • Partnerships • You don’t have to build it all yourself! • You may need to build to standards. • Do yourself a favor: Read “Information Rules” How to Version? > Implement to achieve the design

  41. Summary • Why version? • Pricing is a challenge • How will you optimize your profits? • Differentiation is one key • Lessens competition and facilitates price discrimination • How to version? • Identify important attributes • Know thy customers’ utility function • Design to optimize on those attributes • ATAM, COCOMO II, Cobb-Douglas, and so forth • Implement to achieve the design • Metrics, CMM, value-subtraction, and so forth

  42. Questions? “You must design desirability into the product from the start… Desire is an emotional state, the anticipation of joy, a bittersweet gladness at the prospect of gratified need. “Imagine and identify the few properties of the software that will gratify the need… Visualize the properties, desire them for yourself… Meditate on the nature of the properties you’ve identified, and evaluate the versions of your design in their light.” J. McCarthy. “Dynamics of Software Development”, Microsoft Press, 1995, p 70.

More Related