1 / 36

Code Properties Lecture

Code Properties Lecture. CS 552 Spring ‘08. 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. Exploiting the U-curve.

lamar-tate
Download Presentation

Code Properties Lecture

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. 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

More Related