Re: Why does Software have bugs?
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Sat, 10 Mar 2007 18:45:11 GMT
Responding to Viju...
Why does Software have bugs?
A million Dollar question!!!
Why does Software have bugs?
There are many reasons for Bug in software, Most are man introduced
and some are machine oriented.
If the bug is in the software, it is there because a human put it there. (If the defect is outside the scope of the software it is only manifested in the software.)
There is no software analog for things like wear, brittle failure, corrosion, and other deterioration failures in industrial products. If the software is correct initially it will remain correct until the requirements change. The tricky part is constructing it correctly in the first place.
Here is the the broad list:
1. Miscommunication or no communication -
As to specifics of what an application should or shouldn't do (the
application's requirements).
In most texts this category is called something like "requirements defects". Requirements defects exist in the SRS (missing, incorrect, vague, untestable, etc.) because it was improperly formed. Requirements defects exist in the software because the developer misinterpreted or misunderstood the requirements.
2. Software complexity -
The complexity of current software applications can be difficult to
comprehend for anyone without experience in modern-day software
development. Windows-type interfaces, client-server and distributed
applications, data communications, enormous relational databases, and
sheer size of applications have all contributed to the exponential
growth in software/system complexity. And the use of object-oriented
techniques can complicate instead of simplify a project unless it is
well-engineered.
I don't see complexity as a cause of defects. Complexity /correlates/ with defect content because humans have difficulty managing complexity. The cause of the defect is still a developer screwing up in a specific way.
3. Programming errors -
Programmers, like anyone else, can make mistakes.
If one is going to identify programming errors, I think one should also identify analysis and design errors for symmetry.
However, most texts restrict "programming errors" to incorrect use of the language syntax and semantics (e.g., forgetting the second '=' when coding an equality condition in C).
4. Changing requirements -
The customer may not understand the effects of changes, or may
understand and request them anyway - redesign, rescheduling of
engineers, effects on other projects, work already completed that may
have to be redone or thrown out, hardware requirements that may be
affected, etc. If there are many minor changes or any major changes,
known and unknown dependencies among parts of the project are likely
to interact and cause problems, and the complexity of keeping track of
changes may result in errors. Enthusiasm of engineering staff may be
affected. In some fast-changing business environments, continuously
modified requirements may be a fact of life. In this case, management
must understand the resulting risks, and QA and test engineers must
adapt and plan for continuous extensive testing to keep the inevitable
bugs from running out of control.
When the requirements change one must implement the new requirements as if they were original requirements. Defects are inserted in exactly the same ways, so I don't see any causative basis for this category.
The only thing that is relevant for requirements changes is that it is often more difficult to modify 3GL code than to write it in the first place. However, like complexity, that difficulty doesn't cause defects; it only correlates with defect insertion. Thus an array indexing error is still an array indexing error whether it was inserted in response to original requirements or in response to a change in requirements.
Aside from the technical issues, I think your categories are too broad to be very useful. The main reason one wants to know WHY bugs are present is so that one can modify one's construction processes to prevent them in the future. But that sort of process change usually requires much better definition of the root cause. Thus preventing "programming errors" is far to vague to be remotely helpful in identifying something specific to do to prevent such errors in the future.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.
- References:
- Why does Software have bugs?
- From: viju
- Why does Software have bugs?
- Prev by Date: Re: Why does Software have bugs?
- Next by Date: Re: Why does Software have bugs?
- Previous by thread: Re: Why does Software have bugs?
- Next by thread: Re: Why does Software have bugs?
- Index(es):
Relevant Pages
|
Loading
