Information Technology Reference
In-Depth Information
For most of its useful life, the usage of any software in the production
environment is very repetitive in nature. Further, because there is no
physical wear and tear, the rate at which problems occur does remain the
same. The reality, however, is that during the course of its usage, there
is a likelihood that the software system (and the ecosystem around it) has
been tinkered with, through customizations, higher data volumes, newer
interfaces to external systems, etc. Each time such changes occur, there
is the chance that new points of failure will be introduced. As keen
practitioners, one should be wary of such evolving systems. Make a call
regarding the migration of the production environment (see Chapter 11
on migration). This call will be based on more abstract conditions than
simply the rate at which bugs are showing up or their probability — it
will depend on one's experience in handling such systems.
Known but Not Followed: Preventing Failure
Software systems fail for many reasons, from the following of insufficient
R&D processes during development to external entities introducing bugs
through a hardware or software interface. Volumes have been written
about the importance of and the critical need for:
A strict QA policy for all software development, customization, and
implementation
Peer and buddy reviews of specifications, software code, and QA
test plans to uncover any missed understanding and resource-
specific flaw patterns
Adhering to documentation standards and following the documen-
tation absolutely
Detailed end-user training about the system, usage, maintenance,
and administration
Feedback from user group members who will interface with the
system and use it on a day-to-day basis
Proper availability of hardware and software infrastructure for the
application based on the criticality of its need
Frequent reviews, checks, and balances in place to gather early
warning indicators about any untoward system behavior
There is little need to reiterate the importance of this list. The question
one wants to tackle is: if these things are so clearly recognized, why do
we continue to see increasing incidence of failure in software systems?
Or do these policies come with inherent limitations because of which
they cannot be followed in most software life cycles?
Search WWH ::




Custom Search