Software Bugs A Software Architect Point Of View

Software Bugs A Software Architect Point Of View

• 1.
  Software Bugs -A Software Architect point of view By: Shahzad Sarwar To: Development Team, Management Date: 28th Feb 2010
• 2.
  Table of Content 3.1.Arithmetic bugs......................................................................................................3 3.2.Logic bugs..............................................................................................................3 3.3.Syntax bugs............................................................................................................3 .....................................................................................................................................3 3.4.Resource bugs........................................................................................................3 3.5.Co-programming bugs...........................................................................................4 3.6.Functional bugs......................................................................................................4 3.7.Teamworking bugs ................................................................................................4 Objective:  To Analysis reasons of bugs in PCMS, Pegasus Cargo Management System.  To study the nature and classification of bugs.  To suggest a line of action for reducing bugs in application.
• 3.
  1. Bugs inSoftware Development A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. 2. 20 Reasons for Bugs I. Lack of business domain. II. Lack of techno skills. III. Unfamiliarity with programming language IV. Unclear requirements V. Incorrect architecture VI. Incomplete design VII. Typos VIII. Inadequate understanding of interfaces IX. Inadequate understanding of standards (e.g. TCP/IP, ODBC, SQL, etc.) X. Poor documentation for legacy system XI. Design based on outdated requirements XII. Code written to outdated design XIII. Poor design for future expansion (e.g. hardwired constants, buried assumptions, etc.) XIV. Conflicting requirements XV. Laziness – the desire to use the easiest to implement solution. XVI. Bad fix of a previous problem XVII. Last minute changes/Lack of proper version control. XVIII. Lack of Unit testing by developers. XIX. Compromises made in req/design to meet delivery schedules. XX. Change: to requirements, infrastructure, tools etc., because it introduces the likelihood of all of the above to happen. 3. Common types of computer bugs 3.1. Arithmetic bugs  Division by zero  Arithmetic overflow or underflow  Loss of arithmetic precision due to rounding or numerically unstable algorithms 3.2. Logic bugs  Infinite loops and infinite recursion  Off by one error, counting one too many or too few when looping 3.3. Syntax bugs  Use of the wrong operator, such as performing assignment instead of equality test. In simple cases often warned by the compiler; in many languages, deliberately guarded against by language syntax 3.4. Resource bugs • Null pointer dereference • Using an uninitialized variable • Using an otherwise valid instruction on the wrong data type (see packed decimal/binary coded decimal) • Access violations
• 4.
  • Resource leaks, where a finite system resource such as memory or file handles are exhausted by repeated allocation without release. • Buffer overflow, in which a program tries to store data past the end of allocated storage. This may or may not lead to an access violation or storage violation. These bugs can form a security vulnerability. • Excessive recursion which though logically valid causes stack overflow 3.5. Co-programming bugs  Deadlock  Race condition  Concurrency errors in Critical sections, Mutual exclusions and other features of concurrent processing. Time-of-check-to-time-of-use (TOCTOU) is a form of unprotected critical section. 3.6. Functional bugs  Lack of functionality  Misunstanding of requirement specfications. 3.7. Teamworking bugs  Unpropagated updates; e.g. programmer changes "myAdd" but forgets to change "mySubtract", which uses the same algorithm. These errors are mitigated by the Don't Repeat Yourself philosophy.  Comments out of date or incorrect: many programmers assume the comments accurately describe the code  Differences between documentation and the actual product 4. Tips For Avoiding Bugs:  Read Bugs reasons identfied in section 1daily and act accordingly.  Be a Good Debugger  Adopt a Bug Management and Tracking Methodology.  Code Reviews. Four eyes see more than two. Pair programming is a good technique.  Using log files or live logging during development and production usage is an important and useful technique to identify bugs.  Use automated error and exception reporting techniques.  Unit and regression testing is must.  Test-driven development (TDD) is a software development technique that relies on the repetition of a very short development cycle: First the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. 5. Conclusion:  All developers must read the reasons, classification and tips for bugs once a week and try to act accordingly.  Following a TDD approach to software development can help a lot for developers and software development team in general for solving common problems in testing / bugs management.
• 5.
   Bug frees software is a myth. There is a trade off between bug free software in first strike and increase in cost of software development. If we try to create software bug free then software development cost is increased considerable.  Lets calculate DRE for PCMS. Defect Removal Effectiveness: (or efficiency as used by some writers) is calculated: DRE = Defects removed during a development phase Defects latent in the product at that phase x 100% Example: The Defect Removal Effectiveness for each of the phases would be as follows: Requirements DRE = 10 / (10+3+0+2+1) x 100% = 63% Design DRE = (3+18) / (3+0+2+1+18+4+5+2) x 100% = 60% Coding DRE = (0+4+26) / (0+2+1+4+5+2+26+8+7) x 100% = 55% Testing DRE = (2+5+8) / (2+1+5+2+8+7) x 100% = 60% Development DRE = (Pre-release Defect) / (Total Defects) x 100% = (10+3+2+18+4+5+26+8) / (10+3+2+1+18+4+5+2+26+8+7) x 100 = 88% The longer a defect exists in a product before it is detected, the more expensive it is to fix.  So, Happy Bug fixing for PCMS. 6. References: http://www.westfallteam.com/Papers/defect_removal_effectiveness.pdf http://en.wikipedia.org http://www.google.com