Course - DT249/1
Subject - Information Systems in Organisations
Semester 2, Week 10
INFORMATION TECHNOLOGY REGULATION AND COMPLIANCE
INTERACTING WITH COMPUTERS
Textbooks?
The Laudon and Laudon book,
‘Management Information Systems’
(Seventh Edition) –
 IT Regulation and Compliance :
all of Chapter 15
 Interacting with Computers :
Chapters 6 (6.2) and 10 (10.4)

2
Information Systems Management and the Law

The law is the set of rules that can be enforced
in a court. There are many sets of laws and they
exist in a jurisdiction.

A jurisdiction is usually a geographical area
controlled by government or royalty and might
be, for example, a province, state, principality or
country.
3
IS Management and the Law (2)

The nature of organisations is such that they
are subject to ‘laws of the land’ and they will
also have internal rules and policies.

The information systems of an organisation –
because of their complexity and expense –
become subject to some of these laws and
policies.
4
What is Regulation?
Regulation, in the context of information
systems and the law in Ireland come under laws
of privacy and ethical trading with e-commerce
established by the European Union.
 There are no specific laws governing all
information systems in Ireland. Regulations for
technology are often associated with the Data
Protection Act and trading acts. You could say
that regulation in information systems comes
mainly from individual contracts set up by
organisations.

5
What is Compliance?

Where there are regulations – either by law or
company policy, compliance could be seen as
observance of the official requirements of the
regulation(s).

The act or process of complying with a demand
or recommendation that comes from regulation
is usually a task for a member of management.
6
Legal Issues
The laws associated with information technology have
many aspects. We can look at commonly discussed
legal issues related to information systems or IT:
◦
◦
◦
◦
◦
◦
◦
◦
Contracts
Outsourcing
Software licencing
Data protection
Acceptable use
Intellectual property rights
Computer fraud
Taxation
7
Contracts

Contracts are legal documents defining the legal
implications of buying, selling or becoming
involved with products and services of – in this
MIS context – hardware and software systems
and the issues surrounding them.

Contracts can take many forms – what follows
is a general, basic description of a contract.
8
Contracts (2)

The structure of a contract in our context is,
generally:
◦ The date on which the contract was entered
into
◦ The names and addresses of those entering
the contract
◦ A description of what the contract is about –
having titles such as ‘Background’, ‘Recitals’ or
‘Whereas’
◦ Definitions of terms used in the contract
◦ Provisions made by one party (e.g. Supplier)
◦ What must be paid to the provider (supplier)
9
Contracts (3)

Buying hardware, software and/or
services (for support and maintenance,
very often) often involves a contract – a
contract for procurement or a contract
of procurement.
10
Hardware Procurement Contract

The details for a hardware procurement
contract might include:
◦
◦
◦
◦
◦
◦
◦
A description of the hardware
A warranty for the quality of the hardware
Delivery dates
Price
Acceptance testing (description)
Future maintenance description
Training
11
Software Procurement Contract

Software purchase is much more complex in
terms of contract design. The software may be
developed specifically for the organisation
(bespoke) or be ready to sell ‘off-the shelf’.

More of this type of contract is mentioned in
the section on Software Licencing.
12
Software Procurement Contract (2)

The contract for procurement is carefully
drawn up to reflect what type of software will
be provided, what the software is required to
do, whether there is a maintenance feature to
the deal, what provision there is for the
cessation of the supply company and many
other aspects of law surrounding the idea of
‘keeping the software working’.
13
Services (Consultation) Procurement
Contract
If buying consultancy services – as distinct from
maintenance and support – where there is a need to
consult on design and implementation, for example,
the contract details might include:
◦ Definition of deliverables – what the consultant is
expected to do
◦ Payment arrangements
◦ Copyright and confidentiality
◦ Insurance (professional indemnity)
◦ Key personnel listing (A list of people expected to be
involved in the consultant’s interviews, questionnaires,
etc.)
◦ Termination arrangements
14
Outsourcing

In the context of Management Information
Systems or Information Systems in
Organisations, outsourcing is the supply of
goods and/or services to a client – which could
be an individual or an organisation. Legally, there
are usually contracts involved. Types of contract
are:
◦ Facilities management
◦ Business process outsourcing
◦ Application service provision
15
A Contract for Outsourcing

It is difficult to specify a typical contract
for product or service outsourcing, but –
very generally – a contract for software
services, as an example, may contain:
◦ The statement of requirements
◦ The technical solution
◦ An output specification
16
A Contract for Outsourcing (2)

Similar to hardware, software and services
procurement, there is often a special contract
that is applied to outsourcing called a Service
Level Agreement (SLA).
An SLA often has the details of:
◦ Service levels to be achieved
◦ Targets for service levels
◦ Mechanisms for monitoring and reporting service
levels against those targets
◦ Consequences of failure to meet targets
17
Software Licencing
One might view software licencing as another
form of contract.
 A licence should confirm that the software
supplier owns the copyright in the software or
has the right to licence it to the organisation.


Usually, the software supplier is not selling
ownership of software to an organisation but
the permission to use it as they wish. This leaves
the supplier able to provide copies of the
software to other people or organisations.
18
Software Licencing (2)

Usually a contract is drawn up – called the licence
agreement, since the licence is really a legal
agreement between the software supplier and a
client. (The client being the organisation, for
example.)

There are variations in such agreements;
◦ Is the licence restricted to one office, one department,
one organisation or can the software be lent to ‘sister
companies’?
…/ continued
19
Software Licencing (3)
◦ Is there a user restriction? Does the agreement
allow up to, say 20 users? Do extra users require
individual licences or another group licence?
◦ Are there time constraints? One year? Two Years?
◦ Are there any other restrictions?
20
Data Protection

As an organisation processing data one must
ensure that the processing is lawful.

The data must have been obtained fairly and
lawfully.

When obtaining data from a third party you
must inform the subject of the data that you
have data pertaining to them, telling the subject
why you are using the data and how you will
use them.
21
Data Protection (2)

Personal data must be:
◦
◦
◦
◦
◦
◦
Fairly and lawfully processed
Processed for limited purposes
Adequate, relevant and not excessive
Accurate
Not kept longer than necessary
Processed in accordance with the data subject’s
rights
◦ Secure
◦ Not transferred to countries without adequate
protection
22
Acceptable Use

Employees use computers for their information
work – they may also use their employer’s
computers for personal matters, such as
booking a cheap flight, buying books and gifts
and sending e-mails to friends and family.

While all of these are viewed in different terms
– from ‘perks of the job’, through ‘a bit of a
cheek’ to ‘an offence suitable for reprimand’ the
truth is that they are not the Crime of the
Century!
23
Acceptable Use (2)
The view may be ‘acceptable use’ of computers
through to ‘not very acceptable use’ but hardly
ever make it out of the ‘grey area’ into misuse
of computer systems.
 Misuse might be seen as an

◦ excessive waste of staff time and resources,
◦ actions exposing the organisation to claims for
discrimination, harassment, defamation or worse,
◦ failure to include information that results in criminal
liability.
◦ (On the employer’s side;) health and safety
requirements for screens and other computer
equipment must be met.
24
Acceptable Use (3)

Usage policies
Computer usage policies are very often established
because employers can be held responsible for
wrongful actions carried out by employees in the
course of their employment.
25
Acceptable Use (4)

Common usage problems are:
◦
◦
◦
◦
◦
◦
◦
◦
Racial harassment
Sexual harassment
Downloading pornography
Defamation of management, customers or
competitors,
Breach of confidence
Copyright infringement
Hacking (into systems)
Breaches of the Data protection Act
26
Intellectual Property Rights

Rights on intellectual property are laws related,
in the current context of information systems in
organisations, to software licensing.

Types of intellectual property:
◦
◦
◦
◦
◦
Patents
Design
Copyright
Database right
Trade marks
27
Computer Fraud

Computer fraud is common and undesirable –
that is a given!

Many Management Information Systems service
providers see the responsibility of avoiding this
fraud to belong to the organisation itself.

Corporate governance is the term for the idea
that an organisation ‘watches out’ for computer
fraud.
28
Computer Fraud (2)

Corporate governance can be, in part at least, dealt
with using technical audits. The same audits as
mentioned back in the IT Security notes.

Internal audit activity should contribute to the
organisation’s governance process though which
values and goals are established, communicated and
accomplished. This is the responsibility of
management.
29
Computer Fraud (3)

The European Confederation of Institutes of
Internal Auditing (ECIIA), of which IIA - UK and
Ireland are members, has, in documentation,
described how the professional practice of
internal auditing makes a positive contribution
to achieving good corporate governance and
effective risk management in organisations
based in Europe and beyond.
30
Taxation
E-commerce means that organisations can trade
across borders.
 There is an Electronic Commerce Act,
established by the Oireachtas in 2000.


A Communications Regulations Bill (2007)
amended the state law on e-commerce, giving
ComReg more power in controlling data and
information flow on the internet, with regard to
buying and selling.
31
Taxation (2)

Issues for taxation in e-commerce include:
◦
◦
◦
◦
Identification of a transaction
Identification of the parties to a transaction
Verification of the details of the transaction
Application of the correct taxing rules and
remittance to the taxing authority
◦ Generation of an audit trail.
◦ The country of the supplier, generally, has the
government to which the tax laws apply.
32
End of Part ‘Regulation and
Compliance’

That covers Information Technology
Regulation and Compliance.

The second half of this lecture reviews
the ideas around Interacting with
Computers.
33
Interacting with Computers

What we are looking at with this topic,
largely, is Human-Computer Interaction
or, in a narrower field, GUIs (Graphical
User Interfaces).
34
Interacting with Computers (2)

Interacting with computers is improved by
‘good usability’.

What is that?

A computer system has usability – whether it is
easily usable or difficult to use is measurable.

Usability, like many features of systems, can be
‘designed in’…
35
Design Principles for Usability

When designing a system it is worth taking the
USER into account! Principles for good design
of this sort include:




Early focus on the users
Empirical measurement
Iterative design
Integrative design ( - help for users, training,
documentation, etc in parallel to the technical
design)
36
Usability
Early focus on users
 Bring the design team into direct contact with
the users right from the start.
 Get the user involved so they can instill their
knowledge into the design process.
37
Usability (2)
Empirical measurement
 Actual behavioral measures of
 learnability
 usability
 Testing of appropriate task or concepts - access
speeds, time to learn procedures - remembering that
novices are different from experts.
 Collect the users’ thoughts (interviews,
questionnaires…)
 Collect the users’ mistakes,
 Collect the users’ attitudes.
38
Usability (3)
Iterative design
 Incorporate the results from the tests into the
next prototype
 Set goals for the system
 Get feedback on evaluation
(Evaluation criteria next)
39
Usability (4)
 Evaluation criteria
 easy to use
 user friendly
 easy to operate
 simple
 responsive
 flexible
40
Usability (5)
Integrated design
 Build the online help, prepare training,
documentation AND process modules (coded
programs) at the same time.
41
Usability Definitions

Usability is task related, people related and
function related. It has cognitive, behavioral, and
communicative components.

To be truly usable a system must be compatible
not only with the characteristics of human
perception and action but, and most critically,
with user's cognitive skills in communication,
understanding, memory and problem solving.
42
Usability Definitions (2)

Designing a usable system requires:
◦ understanding of the intended users.
◦ the amount of time they expect to use the
system.
◦ how their needs change as they gain experience.
43
Usability Design
(Back to: )
Early focus on the user
 What: understand the users’ cognition, behaviour and
attitude in relation to the goals of the organisation.
 How: interviews, observations, discussions, working
with the users.
Empirical Measurement
 What: tasks and dependent measures.
 How: testing - protocol analysis, observation,
interviews, etc.
44
Usability Design (2)
Interative design
 What: the problems encountered are to be
corrected and measure again.
 How: an evolving system – prototyping.
Integrated Design
 What: a parallel development of interface, help,
documentation, training and measurement.
45
Measurable Human Factors
Goals for usability
◦ Time needed to learn - how long does it take for
typical users to learn to use the commands
relevant to a set of tasks?
◦ Speed of performance - how long does it take to
carry out the benchmark set of tasks?
◦ Rate of errors by users - how many and what
kinds of errors are made in carrying out the
benchmark set of tasks?
…/continued
46
Measurable Human Factors (2)
◦ Subjective satisfaction - how much did the users
like using aspects of the system?
◦ Retention over time - how well do users maintain
their knowledge?
47
Cognitive Engineering
 Learning is a relatively permanent change in
behaviour resulting from conditions of practice.
 Human learning then is the association of one item
with another item (Associated learning).
 Pairs of stimuli are introduced, a mental association
is made for them, and the stimuli then become
interrelated.
 Future learning can then depend upon past learning
(Constructivism).
 People develop new cognitive structures by using
metaphors to cognitive structures they have already
learned.
48
Cognitive Engineering (2)
 The metaphor is a model or structure or
conceptual framework which helps bridge any gap
between what the person (user) knows and what is
to be learned.
 Metaphors spontaneously generated by users will
predict the ease with which they an master a
computer system.
 If this is indeed the case then systems designers
must understand and employ the use of metaphors
in system designs.
49
Cognitive Engineering (3)
Eight recommendations to aid both the user and designer in
build effective systems
1. Find and use appropriate metaphors in teaching the
naive user a computer system. A metaphor must have
a suitable domain for a given system and given user
population.
2. Given a choice between two metaphors choose the
one which is most congruent with the way the system
works.
3. Assure that the correct attitude is presented. Costs
of ignoring this recommendation range from user
dissatisfaction and reduced productivity to sabotage.
50
Cognitive Engineering (4)
4. When more than one metaphor is need to
represent a system, choose metaphors that are
similar enough, but not to similar that confusion
results.
5. Consider the probable consequences to users
and system designers of each metaphor used.
This is the evolving state from novice to user.
Two path are possible: one leading to directly to
the system, the other to a new metaphor.
6. The limits of the metaphor should be pointed
out to the user.
51
Cognitive Engineering (5)
7. The intent of the metaphor in the beginning is to aid
understanding and usability; for the continual user it is no
longer necessary. The metaphor is used also as a
motivator, at first to get the user to use the system, then
to make him productive and keep his interest.
8. Provide the user with an exciting metaphor for routine
work and eventually present the user with advanced
scenarios requiring different action.
52
Cognitive Engineering (6)
Learning is a relatively permanent change in
behaviour resulting from:
 Elaboration, association, practice, rehearsal.
Metaphor - a mental model, structure, or
framework which help bridge any gap between
what a person knows and what is being
attempted to be learned.
53
Cognitive Engineering (7)
Goals
◦ To understand the fundamental principles of
human action and performance relevant to the
principles of system design.
◦ To devise physical systems that are pleasant to
use.
◦ Psychological variables - goals, intentions and
attitudes
◦ Physical variables - pertain to to system.
54
Human-Computer Dialogue
Computer based systems should be
easy to learn and remember, effective,
and pleasant to use.
These are testable usability behavioral
measures.
55
Cognitive Engineering (8)
Nine basic categories of usability problems:
1.
2.
3.
4.
Simple and natural dialogue: The dialogue should be simple and
clearly stated. It should not contain any irrelevant information. The
information should appear in a natural and logical order.
Speak the user's language: the dialogue should be expressed in the
terminology familiar to the user rather than in system oriented
terms.
Minimise the user's memory load: instructions should be visible,
easily retrievable, and simplified. Presentation load should be
reduced when ever possible (i.e. users should not have to
remember file names when they are retrievable).
Be consistent: the terminology and concepts should always be
used in the same manner.
56
Cognitive Engineering (9)
5.
6.
7.
8.
9.
Provide feedback: the system should provide feedback as to what
is transpiring within a reasonable time.
Provide clearly marked exits: clearly marked exits should be
provided to the user in case of mistakes.
Provide shortcuts: system flexibility for the novice and expert.
Menus for the novice and commands for the experts.
Provide Good Error Messages: The error messages should be
constructive and provide meaningful suggestions to the user of
what to do next.
Error Prevention: A careful design that prevents error messages
form occurring in the first place.
57
Cognitive Engineering (10)
Conclusion:
 The identification of specific, and potential usability
problems in a human computer dialogue design is
difficult.
 Usability goals be defined and incorporated into the
design.
 Designers may have difficulties in applying design
principles unless they have simple basic requirements
for the design product.
58
What Next?

That’s it for IT Regulation and
Compliance and Interacting with
Computers.

Next week:
Revision starts with a review of a past
paper.
59