CS 551 Why do software systems break?

1. CS 551 Why do software systems break? Object Oriented Technology can contain the effects of an fault.

2. Tailored OO Application Software Reusable Software Vendor Software User Programs Software Engineering Client Personal Computer Client Workstation Application Server Large Data Server

3. Program Compile CPU 6-18 Months to first release Debug SW Library Link . . . Load CPU Run Procedural Programming

4. Failure Modes Execute a fault to cause a failure, errors are faults. • Benign errors: Process can recover • Fatal error: Process terminates • Catastrophic error: System hang or crash

5. Failure Modes Aging or duration-related memory leaks and fragmentation degrades execution time or space exhaustion, often causing reduced throughput and eventual system failure.

6. Failure Modes Changes in the operating system versions or separate subsystems can affect performance and reliability. The main program has not changed the extended machine and therefore its environment has changed.

7. Failure Modes Hardware degradation which affects system performance can be experienced many ways. Increased error rate on disk drives which are old or dirty; cables and connectors which become intermittent or noisy; etc. These examples are commonplace and have very significant reliability impacts.

8. Debugging Heterogeneous Distributed Applications- event logging system See Dr. Dobbs Journal November 2005 pp. 32-36- http://www.ddj.com/article/printableArticle.jhtml?articleID=184406314&dept_url=/architect/ Commands: Past_Hour; SYNC; Config Beware: Babbling idiots AS OF 9/11/08

9. Create Node Create Node - = = = = = Assign 5ESS R Filter Type Assets - = = = 5ESS 5E 5E C.Alarm C. Alarm Dynamic Bonding 5E C.Alarm Thres Threshold Activate < 1 Week OOD Programming

10. Any meaningful concept of integration must revolve around the objects used by the systems. Systems are integrated to the degree that they use the same objects. Objects are not static in either meaning or structure; the problem is to manage these changes, not stop them. Data do not die when their host system dies. In fact, they grow, becoming integrated with data from other systems. Databases: Key to System Integration

11. Field Support Provisioning Telephone Equipment How Data Gets Corrupted

12. “…[S]ystems are integrated to the degree that they use the same data.” Robert Curtice “…[D]ata are not static in either meaning or structure [and] the problem is to manage these changes, not stop them.” Daniel S. Appleton

13. Client Field Support Field Support Application Server Provisioning Provisioning Logical Update Loop Customer Records Telephone Equipment Large Data Server Update Customer Service Requests Network Changes Feedback for data integrity

14. Data Data 1 Actions Actions 1 Data + Data ++ Data 1 + Data 1 ++ Actions + Actions ++ Action 1 + Action 1 ++ Data integrity through objects A1 A Date & Action Changes B B1 C C1 • Benefits • Inheritance rippled consistent changes throughout • Data and Actions updated “Just-in-Time” • Redundant Data Minimized

15. Robustness 30:1 • It takes three times the effort to find and fix a problem in the test lab then by developers • It takes ten times the test lab effort to find and fix it in the field As of 9/7/06

16. Soaring Revenues VIP WOW!!! Content Storage & Retrieval Arthur’s Ads Transactions Processing James’ Games IEC Networks Hollywood’s Hottest Shop at Home Credit/ Banking Broadband Pizza Universal 123 456 789000 John Doe IP Business Model Network Provider 1 Customer Care Corporate Network Management Level 1/2 Gateways Content Authoring L1G L1G Network Provider N

17. “Testing can show the presence of bugs but not their absence.” E. Dijkstra, inventor of structured programming

18. “Software is only one interpretation of the reality of the problem it is solving.” Jackson “Don’t automate an undisciplined work flow. The computer won’t solve what the customer’s management can’t.” Brooks

19. Functional versus Project organization

20. Bugs Where are they? How many are typically found? Do bugs ever go away?

21. Where are Bugs found? Developers’ System Test Customer’s On-Site Test Customer’s Acceptance Test Soak Site and Training Program Production Use 77% 1% 2% 4% 16% 100%

22. Bugs reported from first two beta sites Found by Developers Sub-system (# source lines of code) Found by customer Total # Bugs A (250K) B (100K) C (113K) D (175K) E (112K) F (25K) Month Jan Feb Mar Apr May June July Aug Sept Oct Nov 118 80 96 58 78 106 108 111 93 105 84 68 45 59 19 30 104 88 60 68 56 95 87 60 69 68 56 82 95 86 124 94 68 14 60 139 174 127 63 94 59 77 87 65 3 15 20 14 17 18 16 10 11 15 16 0 0 0 0 0 0 0 2 4 0 4 32 18 18 18 34 50 32 49 71 90 112 290 260 383 333 308 373 401 326 375 361 332 11 Month Total 155 1,037 692 889 959 524 10 3,742

23. Bug density in mature systems Bugs per 1K New or Changed Source Lines System (# of source lines of code) # Releases A (500K ) B ( 200K ) C (100K ) D ( 50K ) 13 14 8 9 0.76 0.72 1.00 1.14

24. 1. Pilot before deploying 2. Use experts first 3. Invest $ and time in staff 4. Number of OO Architects = 20% staff 5. Number of Object classes = 0.5% function points 6. Design = 30% development cycle 7. Model performance early and often 8. Buy unit test drivers 9. Assign work by feature teams 10. First release break-even; afterwards 3:1 Ten key development processes

25. Top IT Mistakes, Infoworld.com 11.22.04, pp. 35-41 • Outsourcing & Off-shoring fever (or denial) • Open Source fever (or denial) • Discounting any internal & network security threats • Tuning applications solely to Microsoft Servers. • Underestimating the power of PHP or Ruby on Rails or …

26. Inexperienced Software Management • Poor change management • Poor software development leadership • Promoting the wrong people • No independent QA. • No simplification effort. • Hypnotized by vendor marketing.

27. Key Question What’s the problem?