Information Technology Reference
In-Depth Information
such changes will necessarily fit in one's own system just because they
may have worked well in other environments.
It should also be kept in mind that, like a disease lying dormant for
some time, some software problems may not show symptoms immediately.
A seemingly mundane request by a customer to change a field type,
especially that of an index, may affect the stability of the system in the
long term. It may contradict a basic assumption in the system design made
by the original architect or designers of such a system. Such changes
should be introduced after a detailed impact analysis.
Inexperienced programmers can often introduce inadequacies into the
system due to insufficient understanding of the system, tools, technologies
and constructs, or pure human frailties (such as carelessness or tardiness).
Various life-cycle models and programming practices have been created
to overcome these inadequacies. Xtreme
™
programming and Agile meth-
odologies are two examples. Use them to improve developer proficiency
and detect common patterns of mistakes.
Specification and Design Bugs
It has already been emphasized that software is designed to meet customer
requirements. When something does not work, the question naturally
arises if it is not working with respect to the design or the requirements.
The engineering definition of a bug is: something that does not work
according to specification. If the specification itself is incomplete or
inaccurate, then it is a different kind of problem, unlikely to be discovered
by testing. Should we call incomplete specifications bugs? What does it
mean when one hears the engineering team say, “No — it is not a coding
problem. It is a design problem”? The question arises as to whether the
requirement specifications were incomplete, or an incorrect design choice
was made, or the designer overlooked something that should have been
included. With some checks and balances, oversights are likely discovered
during development or testing by comparing the delivery with the require-
ment specifications. It is only when the problem is with the specifications
themselves that things become difficult.
Requirement specifications should be reasonably detailed, consistent,
and useful to all members of the project team: managers, analysts, design-
ers, developers, and testers. A good design maps these requirements to
the software components being built. A good design document should
provide the rationale for preferring a particular design, including a dis-
cussion of other options. The design review process should provide a
high-level overview of how the required functionality was partitioned and
assigned to subsystems or components. Many design review processes
miss this. They concentrate on the design that has been “selected” rather
