Code Properties Lecture

1. Code Properties Lecture CS 552 Spring ‘08 CS 552 Implementation

2. The defect density U curve For Ada, assembler, C, C++, Cobol, Fortran, Pascal, and PL/M systems: Defects per KLOC Average component complexity Ref: Hatton CS 552 Implementation

3. Exploiting the U-curve Inspect components at the high and low ends preferentially over the medium-sized ones, (i.e. those near the middle of the U-curve). CS 552 Implementation

4. Defects per NCKSLOC Average component complexity Truncate In those systems where excessive complexity (or size) has been restricted:- CS 552 Implementation

5. Avoid deep inheritance < Three levels CS 552 Implementation

6. Eliminate Small Components Defects per NCKSLOC Average component complexity CS 552 Implementation

7. Effective defect density curve Defects per NCKSLOC Size of component with ‘average’ component complexity CS 552 Implementation

8. Fault Density < E Faults per 1000 NCSLOC E Testing Time (t) CS 552 Implementation

9. CS 552 Implementation

10. Defect Densities CS 552 Implementation

11. Defect Densities in 2008 • After Release, count all defects and use asymptotic values (E) • The current state of the art for Reliable systems 0.5-1 defects / NCSKLOC, • A reasonable commercial system 3-6 defects / NCSKLOC, • A poor system is likely to have > 15 defects / NCSKLOC . CS 552 Implementation

12. Impact of programming language Defect density is relatively independent of programming language, so • Moving from assembler to any 3GL is a good idea. • Moving from one 3GL to another is a bad idea. • Moving from a 3GL to an OO language is a good idea, iff it is industrial strength CS 552 Implementation

13. Inspections A significant step defect removal: • The evidence suggests that they are 5-10 times more efficient than any other form of defect removal. • The technology is mature, (some 20 years old), and in trained hands, exceptionally effective. • But, too often become breaucratic. CS 552 Implementation

14. Ignoring Inspections This impressive performance is rewarded by being ignored by most of the computing industry • Time-to-Market Pressure • Managers punish errors • Gurus do not suffer fools lightly • Bureaucratic Check Lists CS 552 Implementation

15. Alcatel Inspections circa 1995 CS 552 Implementation

16. HP Inspections, circa 1987 Rate of faults found per hour, (Grady & Caswell CS 552 Implementation

17. Code Inspection Process 1. Inspect newcomers code. 2. Inspect code if bugs are found in system test. 3. Inspect code where there is a long history of change. 4. Measure Code Complexity and inspect the outliers. 5. Ask all programmers to have their code read by someone else. CS 552 Implementation

18. Consider using Formal Methods • They can be are effective, but are not a quantum leap. It depends! • 3:1 defect density reduction is possible • They only appear to work in conjunction with other techniques. • Beware of over-reliance on them • In many system there are algorithms which you can’t get right any other way. • Confuse customer and developers CS 552 Implementation

19. Defects demographics, CAA Study 1997 This data tentatively suggests that either formal specifications lead to unusual fault distributions or that they lead to no code inspections. CS 552 Implementation

20. CAA study of Formal methods CS 552 Implementation

21. Objects can be horrid • Recent studies (Humphrey, Hatton, Tichy, Shepherd & Cartwright) together show: • • C++ OO systems have almost 25% more defects than conventional C or Pascal systems. • • Each defect in a C++ OO system takes between 2 and 3 times longer to fix than a conventional system. This is true for both simple defects AND difficult ones. The whole distribution is right shifted. • Components involved in inheritance have 6 times more defects than non-inheritance components. CS 552 Implementation

22. Object-orientation observation But I have no doubts. Poor code can be produced anytime and anywhere. Les Hatton CS 552 Implementation

23. Remember! “It is possible to produce truly awful object oriented programs and systems.” Bjarne Stroustrup Inventor of C++ CS 552 Implementation

24. Common C++ Errors • Writing ‘ = ‘when you mean ‘==‘ • Function calls without parameters • String duplications • Deleting Arrays and Strings • Trailing ‘;’ after class declarations • Floats, integers and casting • Uninitialized pointers • Memory Leaks • Calling a program "test" CS 552 Implementation

25. Release Documents • Describe features • Describe corrections to troubles • Cross reference software dependencies • Specify limitations or deficiencies • Provide special installation instructions • Provide data conversion instructions • Specify training • Identify new, changed or deleted documents • Maintain software source code • Maintain product lists CS 552 Implementation

26. Coding Style If (cond A) If (cond A) Execute process A Execute Process A If (cond B) If (cond B) Execute process B Execute Process B else If (cond C) Execute process C Execute Process else "check dispatch parameter" CS 552 Implementation

27. What is the value of k in a Process consisting of thread A & thread B? initialize k=4 thread A: thread B: 1A. load k into T 1B. load k into T 2A. ADD 1 to T 2B. ADD 2 to T 3A. store T into k 3B store T into k CS 552 Implementation

28. Heisenbugs Latent faults causing gradual deterioration a software process with respect to the use of some resource resulting in a crash. CS 552 Implementation

29. Case Study: System Administration System • System monitors equipment. • Messages are trigger by events • I/O Buffer Sharing reduces memory required. CS 552 Implementation

30. Trouble Reported • Intermittent hangs reported in the field. CS 552 Implementation

31. Failure Analysis • Latent Fault in Buffer Flow Control. • Software does not return ‘buffer full’ signal. • Messages written to full buffers. • Messages accepted and partially dropped. • Application waits for complete message. CS 552 Implementation

32. Solution • Fix the bug by returning appropriate indicator, or • Re-launch message handler and avoid the problem: • When buffers are half full. • Periodically. • After hang is detected. CS 552 Implementation

33. Feb 2008 Survey Users that expect to any FOSS Office Suite instead of Microsoft Office in 2008

34. Feb 2008 Survey • How will Open Source products reduce your 2008 software budget form 2007?

35. How much will FOSS products reduce 2008 software budgets? CS 552 Implementation

36. Software requirements that expect to be met with FOSS in 2008 CS 552 Implementation