Information Technology Reference
In-Depth Information
land orientation, soil composition, water table, wind (or snow) or envi-
ronmental conditions, etc. So while the building code for earthquakes
may not require anything exceptional if the land is far from a fault line,
the presence of an active railway track nearby may result in similar
conditions and thus must be considered
. Mission-critical software
has been known to fail because of trivial assumptions such as measurement
units (e.g., meter-kg-second instead of foot-pound-second). Developers
may have found it difficult to create a system with definable units, or
perhaps they were unaware of measurement systems used in different
parts of the world. Assumptions that are wrong are a bane of the software
world.
a priori
Execution Failures: Overruns under Pressure
Often, software does not even reach a stage where it is put in front of
users; the project fails before the software is released. The causes of such
failures are usually time, resource, or scope overruns. Many times, project
managers and architects are not 100-percent aware of the domain's com-
plexity or the new technologies that would be used for the proposed
system. Such failures are common in porting projects (see Chapter 11 on
migration) where managers tend to estimate project costs on the basis of
the origin and destination technologies without looking into the details
of the features used. The complexity involved in porting a system from
Microsoft SQL Server DB to Oracle DB can vary immensely if triggers,
stored procedures, and DB-dependent system calls have been used exten-
sively.
Functional Failures
Unclear user requirements and undocumented “understandings” between
the client and the sales team of the vendor are causes of project cost
overruns. In their enthusiasm to close a deal, meet and beat their sales
quota, or because sales people do not have an adequate understanding
of what it will take to deliver the software, project costs may be severely
under-quoted. It is advisable to have a technical person involved with the
sales process, before the final estimates are shared with the client. All
expectations should be documented as formal features in the requirement
specifications. Sometimes the client innocently adds requirements, often
immediately before signing the deal. These can cause several problems.
Nontechnical verbiage such as “one of my sales staff works from another
city and will need a copy of the database on his computer” or “we have
