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

Slides:



Advertisements
Similar presentations
DEVELOPING A METHODOLOGY FOR MS3305 CW2 Some guidance.
Advertisements

Internal Audit Documentation and Working Papers
CHAPTER 4 E-ENVIRONMENT
More CMM Part Two : Details.
Ethics Ethics are the rules of personal behavior and conduct established by a social group for those existing within the established framework of the social.
The Data Protection (Jersey) Law 2005.
ICS 417: The ethics of ICT 4.2 The Ethics of Information and Communication Technologies (ICT) in Business by Simon Rogerson IMIS Journal May 1998.
Customer Service & Customer Protection in MANSELL
Part 4: Evaluation Days 25, 27, 29, 31 Chapter 20: Why evaluate? Chapter 21: Deciding on what to evaluate: the strategy Chapter 22: Planning who, what,
Computers: Tools for an Information Age
Principles and Methods
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
Examine Quality Assurance/Quality Control Documentation
1 User Interface Design CIS 375 Bruce R. Maxim UM-Dearborn.
INTERNET and CODE OF CONDUCT
User Centered Design Lecture # 5 Gabriel Spitz.
Understanding Task Orientation Guidelines for a Successful Manual & Help System.
CENTRAL SCOTLAND POLICE Data Protection & Information Security Stuart Macfarlane Information Governance Unit Police Service of Scotland.
Internal Auditing and Outsourcing
1. Learning Outcomes At the end of this lecture, you should be able to: –Define the term “Usability Engineering” –Describe the various steps involved.
Higher Administration
Copyright © 2003 by Prentice Hall Computers: Tools for an Information Age Chapter 14 Systems Analysis and Design: The Big Picture.
Lecture 5 Part 1 - Security
Chapter 5 E-environment
SYSTEM ANALYSIS AND DESIGN
S/W Project Management
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
G041: Lecture 16 Section B Revision Questions
SEMINAR ON :. ORGANISATION Organizations are formal social units devoted to attainment of specific goals. Organizations use certain resources to produce.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Requirements Engineering
Elma Graham. To understand what data protection is To reflect on how data protection affects you To consider how you would safeguard the data of others.
James Aiello PricewaterhouseCoopers Africa Utility Week 06 International Good Practice in Procurement.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 7: Focusing on Users and Their Tasks.
Multimedia Specification Design and Production 2012 / Semester 1 / week 5 Lecturer: Dr. Nikos Gazepidis
SEG3120 User Interfaces Design and Implementation
Evaluation of User Interface Design 4. Predictive Evaluation continued Different kinds of predictive evaluation: 1.Inspection methods 2.Usage simulations.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 7 Business Aspects of Software Engineering.
BTEC ICT Legal Issues Data Protection Act (1998) Computer Misuse Act (1990) Freedom of Information Act (2000)
The health and safety act was introduced to protect the welfare of people of the workplace. Before being introduced in 1974 it was estimated that 8.
The techniques involved in systems analysis Explanation of a feasibility study:Explanation of a feasibility study: –economic, –legal, –technical, –time.
Systems Development Life Cycle
Course - DT249/1 Subject - Information Systems in Organisations REGULATION AND COMPLIANCE Semester 1, Week 11 1.
Information Security IBK3IBV01 College 2 Paul J. Cornelisse.
Copyright © 2007 Pearson Education Canada 23-1 Chapter 23: Using Advanced Skills.
Course - DT249/1 Subject - Information Systems in Organisations INTERACTING WITH COMPUTERS Semester 1, Week 12 1.
Creating & Building the Web Site Week 8. Objectives Planning web site development Initiation of the project Analysis for web site development Designing.
1 Chapter 13 (Week 13) SYSTEMS MAINTENANCE AND EVALUATION Chapter 13: SYSTEMS MAINTENANCE AND EVALUATION Throughout its life, a system should operate effectively.
Introduced some basic knowledge of the contract First, what is the contract? Contract, also known as contract. China's definition of the contract, the.
University of Sunderland MSc HIM Computer Legislation.
Objectives  Legislation:  Understand that implementation of legislation will impact on procedures within an organisation.  Describe.
Computer Laws Data Protection Act 1998 Computer Misuse Act 1990.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Quality Assurance. Define Quality (product & service) Exceeds the requirements of the customer. General excellence of standard or level. A product which.
ICT Legislation  Copyright, Designs and Patents Act (1988);  Computer Misuse Act (1990);  Health and Safety at Work Act (1974);  EU Health and Safety.
GCSE ICT Data and you: The Data Protection Act. Loyalty cards Many companies use loyalty cards to encourage consumers to use their shops and services.
Implementation of legislation (Chapter 47) By Haley Court.
Data protection—training materials [Name and details of speaker]
ISO 9001:2015 Subject: Quality Management System Clause 8 - Operation
COBIT. The Control Objectives for Information and related Technology (COBIT) A set of best practices (framework) for information technology (IT) management.
Clark Holt Limited (Co. No ), Hardwick House, Prospect Place, Swindon, SN1 3LJ Authorised and regulated by the Solicitors Regulation.
McGraw-Hill/Irwin © The McGraw-Hill Companies 2010 Internal Control in a Financial Statement Audit Chapter Six.
Section 4 Policies and legislation AQA ICT A2 Level © Nelson Thornes Section 4: Policies and Legislation Legislation – practical implications.
Ten Usability Heuristics These are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of.
Internal Control Principles
Systems Analysis and Design
COMP444 Human Computer Interaction Usability Engineering
Nilesen 10 hueristics.
Presentation transcript:

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

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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 s 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 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 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 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 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 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 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 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 Taxation E-commerce means that organisations can trade across borders. There is an Electronic Commerce Act, established by the Oireachtas in 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 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 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 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 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 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 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 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 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 Usability (4)  Evaluation criteria  easy to use  user friendly  easy to operate  simple  responsive  flexible

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

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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 What Next? That’s it for IT Regulation and Compliance andInteracting with Computers. Next week: Revision starts with a review of a past paper.