Topic: Software Bugs - A Software Architect point of view By: Shahzad Sarwar To: Development Team, Management Date: 28th Feb 2010

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 in Software 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