UNIT 8 - Failed Computer Software

and Information System Projects

TABLE OF CONTENTS

CONTENT .......................................................................................................................... 2

1. UNRELIABLE COMPUTERS....................................................................................... 2
1.1 A DEFINITION OF COMPUTER RELIABILITY .................................................................. 2
1.2 WARRANTIES AND DISCLAIMERS ................................................................................ 2
1.3 ETHICAL ISSUES INVOKED ........................................................................................... 3
1.4 THE NATURE OF COMPUTERS AND SOFTWARE AND THE COMPLEXITY OF SUCH SYSTEMS
........................................................................................................................................ 3
1.5 WHAT ARE COMPUTER SCIENTISTS DOING ABOUT IT? .................................................. 4

2. FAILED INFORMATION SYSTEM PROJECT .......................................................... 5

2.1 DEFINITION OF A FAILED INFORMATION SYSTEM PROJECT ........................................... 5
2.2 FAILED I.S. PROJECTS AND PROFESSIONALISM ............................................................. 6

3. VENDOR CLIENT RELATIONSHIP ........................................................................... 7

4. CONTRACTUAL THEORY.......................................................................................... 7

5. PRODUCT SUPPORT.................................................................................................... 8

6. THE PROBLEM OF VAPOURWARE.......................................................................... 9

7. PRODUCT RELIABILITY.......................................................................................... 10

8. LEGAL CONSTRAINTS ............................................................................................. 11

8.1 BREACH OF CONFIDENCE .......................................................................................... 11
8.2 CONTRACT LAW ....................................................................................................... 11
8.3 LAW OF NEGLIGENCE ............................................................................................... 13
8.4 PRODUCT LIABILITY LAW (1987 CONSUMER PROTECTION ACT) ................................ 14

9. SUMMARY................................................................................................................... 14

BIS2061 1 Unit 8
Content

1. Unreliable Computers

1.1 A Definition of Computer Reliability

Computer systems in one form or another are today indispensable in:

• Air traffic control

• Medicine
• Nuclear power stations
• Toxic chemical plants
• Spacecraft
• Missiles
• Ships
• Tanks and
• Other military hardware and software systems

Computer systems are also deployed to maintain financial systems, stock markets and
communication systems. Even in these often life critical applications, it is apparent
from reports of failed computer systems that the reliability of computer systems is less
than would be hoped.

Computer Reliability is defined as:

‘The probability that it will not fail during its period of operation under given
conditions.’

Peter Mellor (Computer Scientist) suggests measures of reliability can include the
number of failures per unit of operating time and the expected length of time that a
system will operate without failing. Like many computer scientists, Peter Mellor
advocates the application of statistical principles to software quality so that, for
example, it may be more acceptable to have many infrequent bugs than a small
number of frequent ones. However, systems can fail not only in their operation but at
various stages in their design and development.

Indeed, failures in computer system development and use are not simply
commonplace, more often than not they are the rule. According to one US survey, an
astonishing 75 percent of all system development projects undertaken are either never
completed or not used if they are completed.

1.2 Warranties and Disclaimers

Given the incidence of faulty software and system failure in general, it is perhaps not
surprising that software developers rarely provide their clients or purchasers with
warranties of any substance. Indeed, if one compares this situation with that of almost
any other form of purchased goods, then it is difficult not to be incredulous. While
televisions, cars, washing machines and computer hardware are sold with worthwhile

BIS2061 2 Unit 8
guarantees of quality and workmanship, the same cannot be said of software. Another
extraordinary aspect of software marketing is the fact that it is the user who generally
pays for software updates. This is especially true of operating systems and large
packages for mainframe machines. In other words, even if the product is faulty or
needs amendment, the user pays the software supplier to provide more correct
versions.

1.3 Ethical Issues Invoked

The issue of computer unreliability and its potential disastrous consequences invoke a
number of questions, which have ethical dimension to them.

• Why can't we build computer systems with the same inherent reliability that
we find in other designed artefacts such as bridges and buildings?
• Why is software not guaranteed in the same way that other purchased goods
are?
• Why does so much poor quality software exist and how can so much of it
appear in important systems?
• Should we entrust responsibility for the conduct of military warfare, the
control of massive energy sources and even (inter) national economies to
computer systems that are less than totally reliable?

1.4 The Nature of Computers and Software and the Complexity of Such
Systems

The ethical dimensions of computer reliability are to some extent bound up with the
nature of computers and software and the complexity of such systems. To a large
degree, the behaviour of existing complex systems is at the outer edge of our
intellectual understanding, so that the ability to know and predict all possible states,
including error states, that a system might take is severely restricted.

A quick calculation provides some powerful support for the above assertion (Forestor
and Morrison, 1990):
‘For example, suppose a system is designed to monitor 100 binary signal in order to
determine the performance of a particular industrial complex, for example, a nuclear
power station. This amount of monitoring is certainly not excessive given the huge
number of valves, pressure pumps and switches that must be used to check the
behaviour of such systems within tolerable limits. Given these 100 different signal
sources, then there are 2100 or 1.27 x 1030 possible combinations of signal inputs.
Now, the path that such a program follows is utterly dependent upon the combinations
of signals it receives in any given period of time, for example, signal values may be
read or updated every few milliseconds. That is, if a particular combination of signals
is registered, then a particular part of the program will be executed, while other,
different parts of the program may be executed for other input patterns. Given the
large number of such subroutines in a program of this scale, then there may be at least
10,000 (104) possible paths through it. This means that the system can exist in at least
1.27 x 1034 possible states, any one which could cause the software to fail or return
information that is wrong.’

BIS2061 3 Unit 8
To test such a program empirically to identify incorrect states and then to correct
them, for example, automatically at a rate of 100 per second, then the software testers
would need some 1024 years exhaustively to test the array of possible states that this
piece of software might conceivably take.

Because of these realities:

• Are programmers and computer scientists unobligated in the event of a

substantial systems failure?
• If such a system kills a person, is the programmer a murderer?
• If a patient dies on an operating table because software running the life
support equipment fails, is the programmer guilty of manslaughter or
malpractice?
• Is the programmer excused if they provide a disclaimer or inform the surgeon
of potential configurations that could cause problems?
• Or is the programmer guilty simply because they provided a system that both
theoretically and practically could not be guaranteed for application in a life
critical situation?

1.5 What are Computer Scientists doing about it?

Much of software engineering in its modern forms concerns itself with methods and
techniques for making software more reliable, useful and trustworthy. Most of this
work can be grouped around a number of rubrics:
Structured Programming

This field stems from the criticisms of the ‘spaghetti like’code that programmers
tended to produce using the earliest high level languages such as FORTRAN and
Cobol. More recent languages, by the very nature of their design, impose structure
and modularity as well as information hiding. Hence, individual programmers on a
large project need not concentrate on minute details that are more properly the
concern of the project manager or those overseeing the production of the software.
This drive to produce more powerful, usable languages still continues.

Program Verification and Derivation

This field is concerned with mathematical techniques for:

1 Proving programs correct once they have been written (verification) and
2 Showing programs to be correct in the process of building them (derivation)

However, the most correct of programs can still be shown to be unsatisfactory or even
useless if it fails to meet the needs of the individual user or organisation. No
mathematical technique can tell the programmer if they have encapsulated the users'
needs adequately or indeed if we have probed deeply enough to discover what they
are.

BIS2061 4 Unit 8
Programming Environments

Programming environments are essentially operating systems and collections of

software tools that aid programmers by providing flexible and powerful ways of
managing complexity of software development. Hence, environments such as UNIX
provide powerful facilities for managing different program versions, updating all files
affected by a modification, sophisticated bug identification, etc.

Human Management

This aspect of software development has also been tackled and a large variety of
methodologies and project management practices are available today. The
assumptions underlying these methodologies are that by appropriately managing and
controlling the software development process in its human-organisational forms:
specifying client need prototyping, documentation, further client consultation, testing
and debugging, etc. a higher quality product can be delivered more reliably.

Professionalism

See Below

Now do Review Questions 1 and 2

2. Failed Information System Project

2.1 Definition of a Failed Information System Project

In conducting a survey of the literature on IS failure Lyytinen and Hirschheim (1987)

identified four major theoretical categories of failed IS:
1 Correspondence failure: This form of IS failure is based on the idea that design
objectives are specified in detail. An evaluation is conducted of the information
system in terms of these objectives. If there is a lack of correspondence between
objectives and evaluation the IS project is regarded as a failure.
2 Process failure: This type of failure is characterised by unsatisfactory
performance. Either, the IS development process cannot produce a workable
system or the development process produces an IS but the project runs over
budget in terms of cost, time etc.
3 Interaction failure: The argument here is that if a system is heavily used it
constitutes a success; if it is hardly used, or there are major problems with using
the system then it constitutes a failure.
4 Expectation failure: Lyytinen and Hirschheim describe this as a superset of the
three other types of failure.

BIS2061 5 Unit 8
Termination Failure

Sauer (1993) criticised the model proposed by Lyytinen and Hirshheim. According to
his account an IS should only be deemed a failure when development or operation
ceases, leaving supporters dissatisfied with the extent to which the system has served
their interests. This means a system should not be defined a failure until all interest in
progressing an IS project has ceased, i.e. termination failure.

Flowers (1996) states:

‘The failure of an information system occurs when the system as a whole does not
operate as expected and its overall performance is sub-optimal.’

He also defines degrees of failure, ranging from ‘flawed but usable’to ‘totally
unusable’, ‘unused’, or ‘absolute disaster’and while there are many flawed IS in use,
it is usually only the absolute disasters that receive the attention of the media.

2.2 Failed I.S. Projects and Professionalism

Sauer maintains that the key conclusion to be drawn from the study of failed IS cases,
is that the idea of failure can rarely be understood satisfactorily solely from a
technical perspective. This is because a definition of the success or failure of a given
case of computer systems development and implementation is as much reliant on: the
cultural, social, economic, and political setting within which it is developed as it is on
the technical quality of its construction. In conclusion, from the study of failed IS
cases, an understanding of the concept of such failures can be determined.

On the basis of Sauer’s conclusion Beynon-Davies attempted to understand why

computer systems development and implementation projects failed, taking a
perspective which was not solely technical so as to provide an adequate explanation.
In the case of the failed London Ambulance Service Computer Aided Despatch
system project, Beynon-Davies interpreted the failure in terms of professionalism. In
his conclusion he wrote that a clear implication of the LASCAD project failure was
that the builders of the LAS system were seen as having neglected a number of duties
defined by professional ethics which contributed towards the failure of the system.
This was one instance of a case, among many reported, where a neglect of
professional ethics had led to the failure of a computer systems project. Such case
histories were particularly useful in allowing for a more realistic view of project
failure, replacing naive simplistic textbook analysis with hard reality case facts.

You can view a library of failed IS projects <link to:

> that have been analysed and their respective www.scit.wlv.ac.uk/~cm1995/cbr/
failures defined in terms of professionalism and ethics.

Now do Review Question 3

Activity 1 – Failed IS Projects

BIS2061 6 Unit 8
3. Vendor Client Relationship
When computer professionals begin work, they typically enter into relationships with
one or several of the following: employers, clients, co-professionals (or the profession
as a whole) and the public (Johnson, 1995). Literature reviews suggests that with
regards to IS development and implementation projects, more often than not, the
relationship between the professional and the client is predominant, which often
invokes ethical and professional issues that can determine the success or failure of
such projects.

Spinello (1995) argues that

‘Because of the persuasiveness and the indispensability of information technology
applications, the computer industry is virtually unique in the powerful leverage that it
can exercise over its customers. Clients with sophisticated applications can find
themselves at the mercy of these vendors as they wait for fixes to software flaws or
product updates.’
Obviously, ‘Untimely delays, defective products, and broken promises about future
product releases’ can cause mayhem in a client's operations, ultimately leading to a
failed IS project. To some extent the power of these vendors emanates from the
complexity of IT products, the ever-rapid pace of technological change and the
specialised body of knowledge and skills they possess. Clients are therefore heavily
dependent on software and hardware suppliers for accurate, honest and open
information, alongside sound and objective advice. This dependence creates special
obligations for the vendor to be conscientious about advising clients.

Activity 2 – Professional Duty to the Client

4. Contractual Theory
To appreciate the duty of the IT vendor to its client base, Spinello first considers the
general obligation of any seller in the free market. A useful model proposed for
expressing this duty of the contractual relationship between a vendor and the
customer. According to Velasquez (Spinello, 1995) from this aspect, the relationship
between a vendor and its customer is based on an explicit or implicit contract, and the
vendor's moral obligations are firmly grounded in this contract. Velasquez highlights
that it is important that in the absence of an explicit, written contract, there is still a
certain tacit understanding between the buyer and seller which constitutes an implicit
contract.

Thus the customer pays a prescribed sum of money and in return receives a product or
service with certain features and functions. Via this transaction both parties enter into
this contractual relationship. Spinello views this contract as a ‘free agreement’that
imposes on both parties the duty to comply with its terms. In addition to the explicit
terms of the contract there are implicit ones, which impose ‘secondary moral
constraints’. It follows that if a contract is really a free agreement, neither party can be
coerced. Moreover, a valid contract implies that the customer has full knowledge of
what they are receiving, implying that there cannot be any misrepresentation about the

BIS2061 7 Unit 8
product features, the warranty, service commitments, etc. Hence, there is an
obligation upon the vendor to honour the explicit terms of the contract along with the
secondary constraints, which include avoiding concealment or misrepresentation and
avoiding any undue influence or coercion.

5. Product Support
Most IT systems require considerable post-sales support and on-going product
maintenance. This is especially true for software products. Customers normally pay
an annual maintenance or licensing fee for this important service, which usually
includes access to a help desk facility as well as new releases or product updates. A
withdrawal of such services can have serious repercussions on a client's operation.
However, it is impossible for vendors to guarantee an on-going service, since they do
not always have control over their ‘own destiny’, i.e. a vendor can be taken over by a
competitor, encounter financial difficulties, go bankrupt, etc. Vendors can, however,
take certain steps to minimise the likelihood that the product will lose its usefulness.
Spinello (1995) advocates a number of steps, which might include the following
actions or policies:

1 ‘In the case of bankruptcy or other grave problems, software vendors should
routinely make source code available to their customers. Many companies already
follow this policy by placing the source code in an escrow account with
instructions that it be given or sold to customers only if support is totally
discontinued. The availability of source code will enable at least some customers
to fix bugs, adapt the software to new hardware upgrades, and so forth.’
2 Vendors must be candid about their future prospects; customers have a right to
know about the essentials of the firm's financial status so that they can assess the
probability that the company will be around to provide post sale services. ‘This
information is especially critical for private companies whose financial data are
not easily accessible. The requirement of ‘full disclosure’ under the contractual
theory would seem to demand that relevant and reasonable financial information
be revealed so customers can gauge the potential life span of the product they are
purchasing.’
3 ‘Vendors must make ongoing product support a major issue if they are negotiating
as a victim in a take-over or as a partner to a merger. They must zealously protect
the rights of their customers for continued support and ongoing product
usefulness.’
4 If it becomes necessary to discontinue maintenance support, IT vendors should
provide customers with adequate notice of their intention. Spinello views a 30-day
notice, as stipulated in most contracts, as inadequate.

In conclusion, a candid commitment will go a long way to fulfil the vendor's implicit
contractual obligations in this area of product support.

BIS2061 8 Unit 8
6. The problem of vapourware
A common problem among vendors of computer products has been the tradition of
promoting and selling products before they are really ready for the marketplace. Many
companies have announced new products before actual release. Such ‘mythical
products’ have become known in the industry as vapourware. Spinello includes in his
category of vapourware real products that are brought to market prematurely, often
without adequate testing or evaluation. In addition, this also often includes
insufficient infrastructure for supporting the new product. Finally, customer support
personnel and others in the organisation must have adequate training in order to
provide a reasonable level of help-desk support and other assistance to the customer
base.

Besides misleading and exaggerated advertising to the introduction of products that

are not ready for the marketplace, perhaps the most common problem is ‘pre
announcing’. Products are frequently announced even though the development of the
new product has not been completed, often before the products have entered beta
testing (i.e. selective customer testing of the new product before they are released to
the general public). Spinello (1995) views the primary intention of most companies is
‘To distract a customer's interest in a competitor's products. In order to win over
customers, companies will imply the imminence of certain features and functionality.
For example, if a vendor begins selling a new software product with many new
exciting features, a competitor might announce that its new version of this software
has the same features and will be available very soon, even though the product is still
in the design stage. In this way they can convince some customers that they shouldn't
‘jump ship’to a competitor but instead wait for the new release.’

Vapourware is quite harmful to its hapless victims since it can be seriously disruptive
to the normal functioning of a business operation. For example, a client might delay
the implementation of important business applications pending an expected new
release, which does not arrive. Such delays may adversely impact on the firm's
efficiency and its ability to control costs. Also, these erodes the trust clients’place in
vendors’claims, damaging a vendor's integrity, credibility and reputation; and
interferes with future business transactions.

The deception involved in vapourware is a violation of the implicit contract between

vendor and client. A contract calls for full disclosure so that the purchaser can enter
into the transaction with the right degree of freedom and knowledge. Full disclosure
would unquestionably require that a vendor be conscientious about the information it
reveals about it products, that it be honest in announcing release dates and in
discussing the status of a new product.

Vendors, to be more responsible, must make a clear distinction between a product

announcement and a statement of future direction. One rule of thumb suggested by
Spinello is that product announcements should be made only when a product has
reached the stage of technological viability, and this is normally when it has been
fully tested and is ready for shipment to customer beta sites. The earlier in the product
cycle that the product is announced, the greater the chance that the product will not be
ready on schedule.

BIS2061 9 Unit 8
7. Product Reliability
A problem related to vapourware is the general reliability of IT products. Reliability is
defined in (Spinello, 1995) as
‘The capacity of a product or system to perform its intended function under normal
operating conditions.’

The ethical question in the area of product reliability concerns the moral and legal
liability of IT vendors for errors and malfunctions that prove to be costly or
disruptive.

A contract requires that the buyer should not be coerced and should receive ‘full
disclosure’regarding the features of the product. Hence, it seems legitimate to require
the vendor not to misrepresent a product in any way or knowingly sell a defective
product. And if the vendor later learns that the product has certain defects, it should
warn its customers about those problems because they have a right to be informed,
even if they seem inconsequential to the vendor. This can be accomplished by means
of a simple warning notice.

In addition, software bugs that destroy data or cause similar disruptive problems
should be rectified immediately. Under these circumstances companies should feel
obliged to fix the bug and issue another release of the product as soon as possible. It
would be difficult to consider a product as viable or merchantable if it corrupts data or
otherwise disrupts a user's application. However, there is no clear legal responsibility
for vendors to correct these bugs if the damage they cause to a client's business is only
financial. Vendors usually avoid legal liability in such cases by stipulating that the
product is warranted on an ‘as is’basis.

Clients also should be given as much information as possible about a product's

compatibility, for example, whether operating system software is incompatible with
application software. It is not clear that the vendor has an obligation to ensure
compatibility with the vast array of software products available particularly in the PC
environment. However, it seems reasonable to demand that vendors do significant
testing for compatibility and inform clients immediately of any incompatibility
information they have acquired.

Finally, clients also have the right to be informed of a product's quality assurance
status. Before a product is released, industry standards dictate that it should go
through extensive internal quality assurance testing and then be sent off to beta sites
for several months (Spinello, 1995). Sometimes in their rush to bring a product to
market release vendors ignore their responsibility for testing. They might limit the
time frame, lower standards, or even bypass beta test sites testing altogether. If this is
the case clients have the right to be informed so they can determine whether they want
to assume the risks involved in purchasing such a product.

BIS2061 10 Unit 8
In conclusion more open disclosure policies will allow customers to make an
‘informed decision’, which is vital to a fair and open contractual arrangement. Any
kind of misrepresentation is a violation of the basic contract between seller and buyer.

8. Legal Constraints
8.1 Breach of Confidence

In a client vendor relationship, breach of confidence is a matter that should also be

considered by both the author of software and the client. The author should satisfy
himself that the client is fully aware of the confidential nature in any of the elements
of the software. The author of the software may provide the client with source code
and the specifications, including systems models, for example, entity-relationship
diagrams, data flow diagrams, entity life histories and flowcharts for the software.
The agreement should spell out the duty of confidentiality in respect of these
materials, reinforcing the common law duty. If the author has access to the client's
information, for example, sales and marketing techniques, Bainbridge argues that
A reciprocal duty can be placed on the author. In the case of bankruptcy or other
grave problems, software vendors should routinely make source code available to
their clients. The availability of source code will enable at least some clients to fix
bugs, adapt the software to new hardware upgrades, and so forth

8.2 Contract Law

Many contracts for the acquisition and use of computer hardware and software are not
sale contracts as such but licence agreements. This is particularly so with the respect
to computer software where the owner of the rights subsisting in the software grants
licences to customers, giving them permission to use the software in return for a
license fee. For such agreements, the existence and scope of intellectual property
rights are of fundamental importance. Although there is some common ground and
some similarity in other provisions, contracts for hardware and software are governed
by different legal rules.

Computer hardware, if it is sold, will be subject to the Sale of Goods Act 1979
whereas an agreement for bespoke software will be within the scope of the Supply of
Goods and Services Act 1982. Bainbridge argues that this distinction is not always
easy to apply in practice because
‘Hardware equipment often incorporates software and the contractual position of off
the shelf software is far from clear. Nevertheless, the classification in terms of the
legal nature of the transaction is important and the suggested approach is to look at
the predominant purpose of the transaction. That is, did the person acquiring the
subject matter think that they were obtaining hardware or software?’

Software

The special nature of software and the fact that it is usually acquired by means of a
license has several legal implications. To begin with, the Sale of Goods Act 1979 does
not apply to computer software. Goods are defined by section 61(1) of the Act as
including:

BIS2061 11 Unit 8
All personal chattels other than things in action and money

It seems unlikely, even if the copyright is transferred with the computer programs,
that intangible computer programs on a magnetic disk or in a computer chip constitute
'personal chattel'. This is because copyright is a thing in action like company shares or
a money order, to be contrasted with more tangible things in possession such as motor
cares and computers.

The Supply of Goods and Services Act 1982 is relevant to those contracts that involve
part services and part goods. As far as goods are concerned the situation is the same
as with a sale of goods contract because the definition of goods excludes things in
action of which copyright is an example. The 1982 Act is relevant, however, if an
independent computer firm or programmer is engaged to write a computer program as
this should come within the meaning of service.

Expert Systems and other types of software which provide advice could, arguably, be
construed as supplying a service and thus fall within the ambit of the Supply of Goods
and Services Act 1982. The dealer who supplies an expert system may be deemed to
be supplying a service, that is, providing the advice available from the system.
However, others, such as experts who provided the knowledge used in the system and
the makers of the system, are responsible (in a non-legal sense) for how the system
operates. This is because the Supply of Goods and Services Act 1982 states that a
contract for the supply of a service means:
A contract under which a person (the supplier) agrees to carry out a service.

If a dealer has been asked to supply a suitable expert system it is possible that, by
doing so, they have carried out a service. By supplying an expert system, the dealer
has enabled the advice giving service to be performed. The customer relies on the
dealer to provide a suitable and effective system and, consequently, there is a duty on
the dealer to select and recommend and adequate system.

Hardware

As far as computer hardware is concerned, this may be purchased outright or hired. If

purchased then the Sale of Goods Act 1979 will apply the usual terms involving:
§ The requirements that the goods must match the description (section 13);
§ Be of merchantable quality and fit for their purpose (section 14); and
§ The seller has the right to sell the goods (section 11(3)) will be implied into the
contract, subject to any valid exemption clauses

If the supplier carries out some work such as assembling and installing the equipment,
the Supply of Goods and Services Act 1982 will apply. If the contract is for the hire of
the equipment, then the Supply of Goods and Services Act will apply, whether or not
installation or other services are provided by the supplier. The relevant provisions in
the Supply of Goods and Services Act 1982 regarding hire agreements include
implied terms about the rights of the supplier to transfer possession of goods, that the
goods must correspond with their description and implied terms about the quality and
fitness for purpose.

Limited Liability and Unfair Contract Terms

BIS2061 12 Unit 8
Legally speaking, matters to which one can have regard in assessing whether it is
reasonable for a supplier to exclude liability includes:
§ The relative bargaining powers of the parties involved;
§ Opportunities to contract with others who do not use the same exclusionary terms;
§ Whether the customer knew, ought reasonably to have known, of the existence
and extent of the term; and
§ Whether the goods were manufactured processed or adapted to the special order of
the customer.
The law governed by the Unfair Contract Terms Act 1977 briefly provides that the
liability for death or personal injury can never be excluded. Liability for other forms
of damage can be excluded, but only in so far as it is reasonable to do so.

Misrepresentation

If you are negotiating with a salesperson with the view to acquiring computer
software, they may make statements regarding the software and its performance.
There are three forms of misrepresentation: fraudulent, negligent and innocent. If the
representation has been made fraudulently or recklessly, i.e. not caring whether it is
true or not, then at common law the remedy of rescission is available. This sets the
contract aside as if it had never been made at all and gives the right to recover any
money laid out. In terms of representation made by salespersons, the approach is to
insist that an express term be inserted into the contract to the effect of the
representation made.

Now do Review Questions 4 -6

8.3 Law of Negligence

Negligence is a part of law known as tort. It imposes legal liabilities on a person who
has acted carelessly. Under certain circumstances a person will be liable to another for
failing to exercise a required duty of care. A claim in negligence does not does not
depend on the presence of a contract, so if the individual injured is someone else other
than the buyer, that individual can still sue. The buyer should also be able to sue on
the basis of breach of contract if the item is defective and fails to comply with the
implied terms such as those concerning merchantable quality and fitness for purpose.
To be able to sue in negligence, three essential ingredients must be present:
1. A duty of care owned to the injured party;
2. A breach of that duty to care; and
3. Consequential loss, which is a direct and natural result of the breach of duty of
care

The fact that an action can be considered negligent regardless of any contract is
important both for computer programmers and manufacturers of computer hardware.
If a publisher licenses a program, the program author could be liable in negligence
even though they were not a party to the license agreement. In the case of computer
hardware, an individual suffering loss or injury as a result of the negligence of the
manufacturer will have a claim in negligence against the manufacturer regardless of
the fact that the hardware was bought from a dealer.

BIS2061 13 Unit 8
There are limitations, however, to the scope of the law of negligence. A computer
programmer or a computer equipment manufacturer will not necessarily be potentially
liable to the world at large in negligence; they will be liable, however, to those whom
they could contemplate being adversely affected by any negligent act or omissions of
theirs.

8.4 Product Liability Law (1987 Consumer Protection Act)

Related to negligence are the product liability provisions contained in the Consumer
Protection Act 1987. Under the Act, a consumer can claim against the producer of a
defective product regardless of the lack of a contractual relationship between them
and without having to show the basic requirements for an action of negligence. A
product is defined by the Act as being any goods including electricity and includes a
product comprised in another product whether a component part or a raw material. A
computer would therefore come within the meaning of product but computer software
might be outside the scope of this part of the Act.

The producer of a defective product is liable for damage resulting wholly or partly
from the defect. A defect is defined by reference to the expectation of safety in the
product and this relates to property damage as well as death and personal injury.

9. Summary
This unit has introduced some of the key concepts and issues invoked by failed
software and failed Information System projects. You have been presented with the
legal constraints related to hardware and software. In addition, major issues invoked
by the client vendor relationship have been addressed.

BIS2061 14 Unit 8