1 / 13

Portability

Portability. Hohmann Chapter 6. The Perceived Advantage of Portability. By supporting multiple platforms, we can address new markets Not necessarily, building a good solution on one platform is better than building mediocre solutions on many (an exception seems to be midrange software)

virgil
Download Presentation

Portability

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. Portability Hohmann Chapter 6

  2. The Perceived Advantage of Portability • By supporting multiple platforms, we can address new markets • Not necessarily, building a good solution on one platform is better than building mediocre solutions on many (an exception seems to be midrange software) • By supporting multiple platforms, we demonstrate that we can meet customers individual needs • Customers want platform specific features, portability moves in the other direction!

  3. Real Motivation for Portability • Developers think writing portable code is cool • Reality is that it is hard and tedious • One or two key customers demanded different solutions • Search for customers within target marked

  4. Key Cost Factors of Portability • Training developers and QA • Purchasing hardware • Testing time (the matrix of pain) • The complexity of managing multiple release cycles • A good rule of thumb: it is easier to justify a portable technology like a DB than an application

  5. Techniques Helpful for Making Portable Applications • Use an interpreted language • Use standards-based persistent storage (XML, ansi SQL) • Use XML for communication between subsystems • Make business logic portable: not buried within system specific resources • Closer to user means less portable. GUIs hard! • Avoid hiding the power of a specific platform

  6. The Matrix of Pain: market driven configuration matrices • Toy Example • 5 operating systems on two platforms • Unix: Solaris 2.7, Solaris 2.8 • Windows: NT 3.5.1, NT 4.0, XP • 2 Web servers: Apache, IIS • 2 browsers: Netscape, IE • 4 DBs: Oracle 8i, Oracle 9i, SQLServer 7.0, SQLServer 2000 • 5x2x2x4 = 80 configurations • Problem: QA can cover 10 times less

  7. Step 1: Remove Invalid Configurations PC = Possible configuration, NS = Not supported, NA = Not Applicable

  8. Step 2: Rank-Order Configurations • Make prioritization based on which configurations: • Are actually installed in the field • Are used by the largest most profitable customers • Are going to be most heavily promoted • Are most easily supported! • Use color coding: must test, should test, would like to test • Or weights

  9. Step 2: Rank-Order Configurations • Use Pareto Chart to analyze the distribution of customer configurations C1 C2 C3 C4 C5 Adopted from: www.isixsigma.com

  10. Step 2: Rank-Order Configurations

  11. Step 3: Make Final Cut 53% revenue from Solaris. Consider all 3 configuration Orthogonality NT 3.5.1 phasing out, only one configuration NT 4.0 Most important configuration, but SQL output identical

  12. Step 3: Make Final Cut Removing IIS. Still the relative most important

  13. All Pairs • Assume n variables with two values • How many configurations? • 2n • Simple upper bound on the number of distinct pairs? • (2n)2

More Related