1. Course - DT249/1 Subject - Information Systems in Organisations INFORMATION TECHNOLOGY REGULATION AND COMPLIANCE INTERACTING WITH COMPUTERS Semester 2, Week 10

2. 2 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)

3. 3 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.

4. 4 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.

5. 5 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.

6. 6 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.

7. 7 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

8. 8 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.

9. 9 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)

10. 10 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.

11. 11 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

12. 12 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.

13. 13 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’.

14. 14 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

15. 15 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

16. 16 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

17. 17 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

18. 18 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.

19. 19 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

20. 20 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?

21. 21 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.

22. 22 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

23. 23 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!

24. 24 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.

25. 25 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.

26. 26 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

27. 27 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

28. 28 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.

29. 29 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.

30. 30 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.

31. 31 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.

32. 32 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.

33. 33 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.

34. 34 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).

35. 35 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’…

36. 36 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)

37. 37 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.

38. 38 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.

39. 39 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)

40. 40 Usability (4)  Evaluation criteria  easy to use  user friendly  easy to operate  simple  responsive  flexible

41. 41 Usability (5) Integrated design  Build the online help, prepare training, documentation AND process modules (coded programs) at the same time.

42. 42 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.

43. 43 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.

44. 44 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.

45. 45 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.

46. 46 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

47. 47 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?

48. 48 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.

49. 49 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.

50. 50 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.

51. 51 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.

52. 52 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.

53. 53 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.

54. 54 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.

55. 55 Human-Computer Dialogue Computer based systems should be easy to learn and remember, effective, and pleasant to use. These are testable usability behavioral measures.

56. 56 Cognitive Engineering (8) Nine basic categories of usability problems: 1.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. 2.Speak the user's language: the dialogue should be expressed in the terminology familiar to the user rather than in system oriented terms. 3.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). 4.Be consistent: the terminology and concepts should always be used in the same manner.

57. 57 Cognitive Engineering (9) 5.Provide feedback: the system should provide feedback as to what is transpiring within a reasonable time. 6.Provide clearly marked exits: clearly marked exits should be provided to the user in case of mistakes. 7.Provide shortcuts: system flexibility for the novice and expert. Menus for the novice and commands for the experts. 8.Provide Good Error Messages: The error messages should be constructive and provide meaningful suggestions to the user of what to do next. 9.Error Prevention: A careful design that prevents error messages form occurring in the first place.

58. 58 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.

59. 59 What Next? That’s it for IT Regulation and Compliance andInteracting with Computers. Next week: Revision starts with a review of a past paper.