DIEB 1.1

Kursusgang 1Oversigt:

• Kurset­ Indhold:­HCI­disciplinen­ Formål­og­evaluering

• Designprocesser­ Vandfaldsmodellen­ Prototyping­ Specifikation­eller­prototype­ Spiralmodellen

• Modellering­af­brugere­ Hvem­er­brugerne­ Modellering­af­krav­ Modellering­af­systembrug

• Tre­eksempler

DIEB 1.2

Design, implementering og evaluering af brugergrænseflader

• Design­af­brugergrænseflader­er­baseret­på­den­disciplin­inden­for­datalogi,­som­kaldes­ Menneske-maskin­interaktion­ Human-computer­interaction:­HCI

• Designet­består­i­at­udforme­computerens­grænseflade­så­mennesker­kan­interagere­fornuftigt­med­den

• Hvorfor er det vigtigt?

• Hvad er udgangspunkt og resultat?

• Hvilke problemstillinger involverer det?

DIEB 1.3

HCI: Hvorfor er det vigtigtOperatørernes fejl? (1)Three Mile Island, Harrisburg, Pennsylvania: 28. marts 197928/3-79,­kl.­4.00­stopper­dampturbinen­automatisk.­Operatørerne­kontrollerer,­at­to­kølevandspumper­starter­men­er­ikke­klar­over,­at­de­pumper­vand­ind­i­lukkede­rør,­fordi­to­ventiler­ved­en­fejl­er­lukkede.

Der­er­to­indikatorer­på­værkets­enorme­kontrolpanel,­som­viser­ventilernes­position.­Men­ventilerne­er­aldrig­lukkede,­og­den­ene­indikator­er­dækket­af­et­reparationsskilt­på­knappen­ovenover.

8­minutter­senere­bliver­operatørerne­klar­over,­at­noget­er­galt,­og­de­opdager­fejlen.­Men­da­er­der­allerede­sket­væsentlige­skader.­Da­kølevandspumperne­ikke­fungerer,­koger­dampgeneratoren­tør,­temperaturen­stiger,­og­kontrolstængerne­aktiveres­automatisk­for­at­stoppe­kernereaktionen.

Operatørerne­aktiverer­et­manuelt­kølesystem,­men­kan­ikke­lukke­ventilen­hertil,­da­der­er­lukket­tilstrækkeligt­meget­vand­ind.­På­kontrolpanelet­viser­en­indikator,­at­der­er­afgivet­en­impuls­til­ventilen,­så­operatørerne­tror,­at­den­er­lukket.

Lidt­senere­styrer­operatørerne­på­to­trykmålere,­der­burde­vise­ensartede­værdier,­men­gør­det­modsatte.­De­antager,­at­en­af­dem­er­i­stykker­men­ved­ikke­hvilken.

DIEB 1.4

HCI: Hvorfor er det vigtigtOperatørernes fejl? (2)De­to­målere­var­faktisk­i­orden,­og­kunne­have­indikeret­for­operatørerne,­at­en­katastrofal­situation­var­under­udvikling.­En­tredie­indikator­kunne­have­ledt­dem­til­den­korrekte­slutning,­men­den­regnedes­for­uvæsentlig­og­var­placeret­forneden­på­bagsiden­af­et­2­meter­højt­kontrolpanel.

I­kontrolrummet­var­der­op­til­40­personer,­tre­lydalarmer­aktiveret,­og­et­stort­antal­af­de­1600­kontrollamper­lyste­eller­blinkede.­Lydalarmerne­blev­ikke­slået­fra,­fordi­det­også­ville­fjerne­de­relaterede­informationer.­Computeren­var­overbelastet,­og­det­varede­flere­timer,­før­de­relevante­informationer­blev­skrevet­ud.

To­en­halv­time­senere­blev­den­tredie­indikator­checket,­og­operatørerne­nåede­frem­til­den­rigtige­konklusion.­De­fik­kølingen­sat­i­gang,­men­det­varede­over­14­dage,­før­man­var­helt­sikker­på,­at­der­ikke­ville­ske­en­nedsmeltning­af­reaktoren.

De efterfølgende undersøgelser konkluderede, at årsagen var operatørernes tåbelige fejl

Charles­Perrow­(1984).­Normal Accidents. Living with High-Risk Technologies.­New­York:­Basic­Books

DIEB 1.5

En anden forklaring påhvorfor operatørerne lavede fejl1. Mange­fejl­i­menneske-maskin­interaktion­(HCI)­skyldes­dårligt­

design,­som­ikke­indtænker­menneskers­evner­og­fejlbarlighed.Dette­fortolkes­ofte­som­åbentbart­forkert­betjening­og­menneskelige­fejl.

2. Godt­design­indtænker­altid­menneskers­evner.

Hvordan kan man så gøre det bedre?

Ulykken­på­Three­Mile­Island­kan­forklares­ved­hjælp­af­to­enkle­begreber

• Mapping­ Relationen­mellem­det­vi­ønsker­at­gøre­og­det­som­det­er­muligt­at­udføre

Eksempler:­komfur,­British­Midland­ Three­Mile­Island:­Der­var­problemer­med­mapningen­af­deres­intentioner­over­på­

systemets­funktioner:­de­manglede­information­og­funktioner

• Feedback­ Information­om­udførelsen­af­en­handling­og­dens­resultat­ Three­Mile­Island:­Der­var­i­flere­tilfælde­ikke­feedback

DIEB 1.6

HCI: Hvad er udgangspunkt og resultat• Udgangspunkt:­

analyseresultater­ Hvem:­aktørtabel­ Hvad:­klassediagram­

og­funktionsliste­ Hvordan:­brugsmønstre­

og­tilstandsdiagrammer

• Design og implementering af brugergrænsefladen

• Resultat:et­evalueret­design­af­brugergrænsefladen

Cash­WithdrawalUse­Case:­Cash withdrawal is started by the

account owner, when he wishes to use his credit card to withdraw cash from an ATM. The account owner inserts his card in an ATM, and is then requested via the screen to type his PIN code. The screen will either show a polite denial, the card will be rejected from the ATM and the process will be cancelled; or the screen will show a menu requesting the account owner to choose an amount of money by typing on the ATM’s keyboard. A new screen requests the account owner to approve the transaction. If the transaction is not approved the account owner is again requested to type an amount. Otherwise the use case ends by the ejection of the card, and the desired amount of money being paid.

Objects:­(to be added later)Functions:­(to be added later)

DIEB 1.7

Problemstillinger: HCI som disciplin (1)• Brug­af­computere­eller­

informationsteknologi­i­menneskelig­aktivitet

• Temaer­ HCI

• Mennesker• Computere• Interaktion

­ Brugbarhed:• Betydning• Vurdering

Computer

Human

DIEB 1.8

Problemstillinger: HCI som disciplin (2)• ACM­komite­til­

design­af­HCI-uddannelser­(1992)

• Se­supplerende­litteratur­på­spiseseddel

DIEB 1.9

DIEB-kurset:Formål og evaluering• Semestermål

­ Viden­og­erfaring­med­design­og­implementation­af­et­edb-system

• Kursusformål­ Give­indsigt­i­principper,­retningslinier­og­omgivelser­til­design­og­

implementation­af­brugergrænseflader.­ Forstå­de­teorier­og­erfaringer,­der­udgør­grundlaget­for­principper­og­

retningslinier.­ Opnå­praktisk­erfaring­med,­hvordan­design­og­implementering­af­en­

grafisk­brugergrænseflade­kan­udføres.

• Dele­(1­modul­hver):1. Videregående­HCI-metode2. Værktøjer­og­biblioteker­til­implementering­af­brugergrænseflader3. Grundlæggende­HCI-begreber­og­brugbarhedstest­(kun­Dat1)4. Programmering­af­brugergrænseflader­(kun­Inf1)

• Evaluering­ Evalueres­gennem­projektet.

DIEB 1.10

Spiseseddel• To­versioner­

af­Dix

• Fokus­på­de­væsentlige­afsnit

DIEB 1.11

Designprocesser

• Vandfaldsmodellen

• Prototyping

• Specifikation­eller­prototype

• Spiralmodellen

DIEB 1.12

Vandfaldsmodellen• Det­klassiske­eksempel­på­en­life-cycle­model

• Hvad­er­ideen?­ Udviklingsprocessen­gennemløber­

et­antal­faser­ Hver­fase­har­et­klart­defineret­

produkt­ Produktet­af­en­fase­valideres­i­

forhold­til­bestemte­kriterier­ Produktet­af­en­fase­er­

udgangspunktet­for­den­næste­fase

DIEB 1.13

Vandfaldsmodellen i Dix• Svarer­til­den­generelle­vandfaldsmodel

• Lidt­andre­navne­på­faserne

Requirements­specification

Operation­and­maintenance

Architectural­design

Detaileddesign

Coding­andunit­testing

Integration­and­testing

DIEB 1.14

Relation til OOA&D

Requirements­specification

Operation­and­maintenance

Architectural­design

Detaileddesign

Coding­andunit­testing

Integration­and­testing

Krav t il brug

Model

Beskrivelse af komponenter

Beskrivelse afarkitektur

Design af komponenter

Design af arkitektur

Analyse af anvendelses-

område

Analyse af problem-område

DIEB 1.15

Erfaringer med vandfaldsmodellen

• Projektledelse­er­simpelt:­Hvorfor?

• Virker­ikke­i­praksis!Tænk på et af jeres tidligere projekter som eksempel

DIEB 1.16

Specifikationer:Transfer of Knowledge (Nonaka)• Et­nøglebegreb­i­knowledge­management

• Spørgsmål:­hvordan­kan­man­overføre­viden­til­andre?

• Skelner­mellem­”explicit­knowledge”­og­”tacit­knowledge”

From

Tacit knowledge

Explicit knowledge

ToTacit knowledge Explicit knowledge

Internalization

Converting­explicit­knowl-edge­into­tacit­knowledge;­learning­by­doing;­studying­previously­captured­explicit­knowledge­(manuals,­documentation)­to­gain­technical­know-how

Socialization

Transfering­tacit­knowledge­through­shared­experiences,­apprenticeships,­on-the-job­training,­talking­at­the­water­cooler

Externalization

Articulating­and­thereby­capturing­tacit­knowledge­through­use­of­metaphors,­analogies,­and­models

Combination

Combining­existing­explicit­knowledge­through­exchange­and­synthesis­into­new­explicit­knowledge

DIEB 1.17

Problemer medvandfaldsmodellen• Baserer­sig­udelukkende­på­specifikationer,­men­de­er­vanskelige­både­at­lave­(overførsel­af­viden)­og­forstå

• Svært­at­uddestillere­brugernes­viden­om­deres­arbejde

• Mange­negative­effekter­af­de­udviklede­systemer

• Krav­ændrer­sig­over­tid• Ikke-tekniske­aspekter­er­svære­at­beskrive

• Tilbagekobling­bliver­nødvendigt

• Fungerer­kun,­når­vi­ved­hvad­vi­vil­have,­og­vi­kan­beskrive­det­præcist­og­utvetydigt

Effects (Zuboff)• Sensory­satisfaction­with­handling­of­

physical­objects­(forms,­books,­etc.)­was­missing.

• Experienced­less­interaction­with­humans­(customers,­supervisors)­and­more­with­computers.

• Did­not­fully­understand­where­data­on­their­screens­came­from­and­what­it­meant.

• Reduced­feeling­of­certainty­and­control­because­of­lack­of­concreteness­(no­names,­no­history,­etc.).

• Less­skill­and­knowledge­of­insurance­claims­required­(the­computer­knows­it).

• More­computer­skills­required.• Routine­work,­just­”pushing­buttons”.

DIEB 1.18

Prototyping• Brug­af­prototyper­er­et­andet­alternativ­til­vandfaldsmodellen

• Hvad­er­en­prototype?

• En­prototype­realiserer­bestemte­egenskaber­ved­et­system

• Brugerne­kan­arbejde­og­eksperimentere­med­den­for­at­illustrere­deres­krav

• Der­findes­forskellige­former­for­prototyper

• De­bruges­på­forskellige­tidspunkter­i­udviklingsprocessen

• Quick and dirtyEarly­implementation­without­prior­analysis­and­design.­Revised­until­the­users­are­satisfied.­Revisions­become­complicated­and­maintenance­is­very­expensive.

• Throw-awayDevelopment­in­order­to­enquire­into­and­express­requirements.­Is­often­described­as­a­”running”­requirements­specification.

• Design-drivenAn­implementation­of­a­design­which­is­as­close­to­the­final­systems­as­possible.­Often­used­for­technical­experiments,­e.g.­with­the­technical­platform.

• Mock-upA­cardboard­or­similar­non-executable­model­of­the­system.

• EvolutionaryA­modifiable,­running­model­of­part­of­a­system.­Is­gradyally­developed­into­the­final­version­which­becomes­the­system.

DIEB 1.19

Eksempel: Mock-up• UTOPIA­project

• Tools­for­graphical­workers­for­page­make-up­and­image­processing.

• Oppose­the­deskilling­that­occurred­when­computers­were­introduced.

• Started­describing­requirements­to­a­tool,­but­that­was­too­abstract­for­the­graphical­workers.

• Made­mock-ups­to­simulate­how­the­computerized­system­would­work.

• The­mock-ups­were­made­of­cardboard­boxes,­overhead­projectors­and­projector­screens.

• Simulation­involved­people­performing­the­operations­of­the­computer.

• A­prototype­was­developed­from­the­experiences­with­the­mock-ups.

DIEB 1.20

Specifikation eller prototype

• Vi­står­over­for­to­mulige­arbejdsformer:­vandfaldsmodellen­(specifikationsbaseret)­eller­prototyping

• Hvordan­vælger­vi?

• Hvilken­arbejdsform­skulle­vi­vælge­til­udvikling­af:­ Et­system­til­registrering­af­køb­af­øl­og­sodavand­i­Kaffestuen­ Et­mobilt­system­til­køb­af­biografbilletter­ Et­system­til­styring­af­et­atomkraftværk

DIEB 1.21

Kontingensfaktorer• Relevansen­af­specifikationsbaserede­metoder­og­prototyping­kan­afgøres­ud­fra­kontingensfaktorer:­ Kompleksitet­ Usikkerhed

Kan­simpelt­defineres­ud­fra­den­tingængelige­information:

Quantity Too much Too little

Quality Too difficult Too unreliable

Complexity Uncertainty

DIEB 1.22

En simpel kontingenmodel

Reference:­Burns­&­Dennis

System Life Cycle

Prototyping

Mixed Methodology

Prototyping

HighLow

High

Low

Complexity

Uncertainty

DIEB 1.23

Typiske kontingensfaktorer (1)• System­developers­ knowledge­about­the­application­

and­problem­domains­ ability­to­make­a­complete­and­

consistent­design­specification­ experiences­with­specification­of­

requirements­in­co-operation­with­prospective­users

­ ability­to­implement­the­requirements­with­the­available­technical­environment.

• Users­ ability­to­describe­the­

application­and­problem­domains­in­a­logical­and­structured­fashion

­ ability­to­specify­requirements­in­cooperation­with­the­systems­developers

­ experience­with­systems­development­and­prototyping

­ understanding­of­design­specifications­and­the­available­computer­technology

­ ability­to­review­the­proposed­design­specifications­of­the­computer­system.

DIEB 1.24

Typiske kontingensfaktorer (2)• Application­Domain­ lack­of­clarity­and­consistency­of­

the­organizational­tasks­ unclear­boundaries­of­the­

application­domain­ broadly­diverse,­complex,­or­

unstructured­tasks­ tasks­are­continously­shifting­in­

response­to­a­turbulent­organizational­environment

• Problem­Domain­ includes­many­complex­objects­

with­complex­relationships­ includes­many­complex­

occurrences­of­events­ the­boundaries­of­the­problem­

domain­are­not­clearly­defined­ boundaries­are­continously­

changing­due­to­environmental­turbulence

DIEB 1.25

Typiske kontingensfaktorer (3)• Computer­System­ ambiguous­and­inconsistent­

computer­system­requirements­exist

­ the­computer­system­entails­a­database­with­interactive,­transaction­processing­and­reporting

­ there­are­specific­computer­system­performance­and­network­data­communication­requirements

­ the­computer­system­to­be­developed­is­partly­incompatible­with­the­development­environment

• Development­Environment­ unreliability­in­the­target­

computing­machinery­or­systems­software

­ unreliability­in­the­development­computing­machinery­or­software

­ insufficient­or­ambiguous­documentation­of­the­development­environment

­ linkages­to­externally­controlled­technologies­like­standardized­internet­clients­or­servers

DIEB 1.26

Kombineret metode:Spiralmodellen• Spiralmodellen­kombinerer­

prototyping­og­vandfaldsmodellen

• Baseret­på­cykler,­som­indeholder­fire­typer­aktivitet

• Den­radiale­dimension­svarer­til­den­samlede­indsats­på­et­givet­tidspunkt

• Vinkeldimensionen­svarer­til­hvad­der­er­opnået­I­en­enkelt­cykel.

• Ved­hver­passage­af­x-aksen­(klokken­3)­tages­en­beslutning

• Beslutningen­baserer­sig­på­risikoanalyse

• Når­alle­risici­er­eliminerede,­fases­der­ud­I­en­vandfaldsmodel

DIEB 1.27

Metoder til HCI-design

• ”Metode”­–­hvad­er­det?

• Hvad­skal­vi­med­metoder?

• ”Metodiske­anvisninger”­–­blødere

• Dix:­fire­kategorier­af­metodske­anvisninger­for­designprocessen:­ Life-cycle­eller­vandfaldsmodellen­ Designregler (senere)­ Usability­engineering (senere)­ Prototyping

• Problem:­hvordan­skal­vi­vælge­og­kombinere­metodiske­anvisninger?To­løsninger:­ Kontingensfaktorer­ Mombineret­metode

DIEB 1.28

Modellering af brugere

• Hvorfor­er­det­nødvendigt?

• Hvem­er­brugerne:­stakeholder­analysis

• Modellering­af­krav­ systembeskrivelse­i­Florence-projektet­ Sociotekniske­metoder:­ETHICS

• Modellering­af­systembrug­ GOMS­ Keystroke

DIEB 1.29

- fordi systemudviklerne ikke forstår brugerne og deres arbejde• Jeg­har­brug­for­hjælp­til­at­udfylde­min­SU-ansøgning

• Vi­starter­på­Aalborg­Universitets­web-sted:

• Vi­finder­aldrig­den­nødvendige­hjælp;­kun­samlinger­af­regler­og­bestemmelser

DIEB 1.30

Hvem er brugerne• Dix­foreslår­stakeholder­analysis

• Eksempel:­airline­booking­system­ Primary­stakeholders:­travel­

agency­staff,­airline­booking­staff

­ Secondary­stakeholders:­customers,­airline­management

­ Tertiary­stakeholders:­competitors,­civil­aviation­authorities,­customers’­traveling­companions,­airline­shareholders

­ Facilitating­stakeholders:­design­team,­IT­department­staff

• Primary­stakeholders­er­dem­vi­er­mest­interesserede­i

• Svarer­til­aktører­i­OOA&D

System

Problem domain Application domain

User

DIEB 1.31

Eksempel: System Description in the Florence Project• Analysis­of­work­conducted­in­a­three-day­seminar­where­both­nurses­and­system­developers­participated.­

• The­purpose­of­the­seminar­was­to­establish­a­detailed­and­precise­understanding­of­nursing.

• The­flow­of­data­was­to­be­described.­At­the­seminar­the­participants­were­trained­in­making­data­flow­diagrams­(Yourdon­1982),­and­were­then­supposed­to­apply­this­tool­to­describe­their­work.

• Three­groups­of­nurses­were­established:­A,­B,­and­C.

• Each­group­included­nurses­from­three­different­wards­and­a­systems­developer.

• An­external­consultant­with­extensive­development­experience­circulated­between­the­three­groups.

• The­nurses’­experience­was­chosen­as­the­starting­point.­While­working­with­the­descriptions­it­became­clear­that­their­experience­was­different:­ Varying­degrees­of­skill.­ Differences­in­the­organization­

of­work­in­different­wards.

DIEB 1.32

Group A• In­group­A,­the­work­was­mainly­

led­by­the­nurses.­The­systems­developer­was­primarily­acting­as­an­advisor.

• The­description­concentrated­on­relations­between­the­manual­routines­of­nursing­and­it­focused­on­the­physical­situation­in­the­three­wards­of­the­participants.

• It­reflected­how­work­was­actually­organized­and­carried­out.

• It­was­an­attempt­to­describe­human­information­processing­instead­of­simple­data­transformation­and­the­contents­of­the­forms­applied.

• The­rules­of­the­method­were­not­strictly­observed:­ A­special­signature­for­informal­

communication­between­various­persons­was­introduced.

­ The­routines­were­not­described­in­the­exact­way­in­which­the­incoming­data­flows­were­transformed­to­the­outgoing­data­flows.­Instead,­the­group­focused­on­criteria­that­were­influencing­the­major­decisions.

­ Various­time­consuming­activities­were­included­in­the­description,­even­though­they­were­not­of­direct­importance­to­the­data­transformation.

­ The­description­also­included­the­nurses’­relation­to­customers­and­local­management­(the­manager­of­the­ward).

DIEB 1.33

Group B and C• The­descriptions­made­by­group­B­and­group­C­differed­much­from­that­of­group­A.

• In­both­groups,­the­system­developer­was­the­most­dominant­person.

• Much­weight­was­attached­to­observation­of­the­rules­and­guidelines­of­the­method,­and­in­this­sense­the­descriptions­produced­were­more­correct.

• The­participants­were­surprised­that­these­two­descriptions­turned­out­to­be­very­different­anyway.

• In­group­B,­there­was­an­experienced­nurse,­and­her­understanding­of­work­in­the­ward­in­which­she­was­employed­influenced­the­description­very­much.

• In­group­C,­the­participants­were­more­equal.­This­implied­that­their­description­gave­a­more­generalized­picture­of­the­work­in­the­three­wards.­

DIEB 1.34

Comparison• On­the­last­day­of­the­seminar,­the­descriptions­were­presented.

• The­nurses­stressed­that­all­three­descriptions­gave­a­strongly­biased­impression­of­“actual”­nursing.

• Group­A­gave­the­most­relevant­picture­of­their­work.

• The­consultant­emphasized­the­quality­of­the­description­from­group­C.

• After­the­seminar,­system­developers,­who­did­not­participate­in­the­seminar,­were­presented­to­the­descriptions.

• They­had­problems­in­understanding­the­descriptions.

• This­especially­applied­to­the­description­produced­by­group­A­but­also­to­the­descriptions­produced­by­group­B­and­C.

DIEB 1.35

Florence Results

• The­descriptions­were­only­applicable­to­a­limited­extent.

• To­supplement­them,­a­number­of­prototypes­were­developed.

• A­prototype­was­developed­in­collaboration­with­the­nurses­at­two­different­hospital­wards.

DIEB 1.36

AlternativETHICS: Basics• Information­system­development­method­

created­by­Enid­Mumford.• Effective­Technical­and­Human­Implementation­

of­Computer-Based­Systems.• Focus­on­the­interaction­of­technology­and­

people• Result:­work­systems­that­are­both­technically­

efficient­and­have­social­characteristics­which­lead­to­high­job­satisfaction.

• ”All­change­involves­some­conflicts­of­interest.­To­be­resolved,­these­conflicts­need­to­be­recognised,­brought­out­into­the­open,­negotiated­and­a­solution­arrived­at­which­largely­meets­the­interests­of­all­the­parties­in­the­situation­...­successful­change­strategies­require­institutional­mechanisms­which­enable­all­these­interests­to­be­represented,­and­participation­provides­these.”

Job satisfaction:­the­attainment­of­a­good­'fit'­between­

• What­the­employee­is­seeking­from­his­work:­job­needs,­expectations­and­aspirations

• What­he­is­required­to­do­in­his­job:­the­organisational­job­requirements­which­mould­his­experience.

Job satisfaction:­the­attainment­of­a­good­'fit'­between­

• What­the­employee­is­seeking­from­his­work:­job­needs,­expectations­and­aspirations

• What­he­is­required­to­do­in­his­job:­the­organisational­job­requirements­which­mould­his­experience.

DIEB 1.37

ETHICS: Methodology1. Why­Change?2. System­boundaries3. Description­of­the­existing­system

(5­different­levels,­operative­tasks­to­whole­system)

4. Definition­of­key­objectives5. Definition­of­key­tasks6. Definition­of­key­information­needs7. Diagnosis­of­efficiency­needs8. Diagnosis­of­job­satisfaction­needs9. Future­analysis10.Specifying­and­weighting­efficiency­and­

job­satisfaction­needs­and­objectives­11.The­organisational­design­of­the­new­

system12.Technical­options13.The­preparation­of­a­detailed­job­design14. Implementation15.Evaluation

Step 4 - Examples of key objectives of the Purchase Invoice Dept.• Key objectives are to ensure that the Company obtains goods and services from suppliers which

are of the right quality and price and arrive on the date promised. Also to provide a satisfying, stimulating work environment for Purchase Invoice and Treasurer's Dept. staff. 

• Relationships with suppliers are often very poor due to inaccurate or delayed payment of suppliers accounts. This is affecting the quality of the supplier's service.

Step 5 - Examples of key tasks of the Purchase Invoice Dept.• The fast, correct payment of suppliers accounts• The fast, correct answering of suppliers queries• The fast, accurate notification to suppliers' of rejected goods and requests for

financial compensation• The monitoring and improvement of the suppliers' service

Step 6 - Example of key information needs• Operating Information

• Information on suppliers and the state of their accounts• Information on payments made

• Problem prevention/solution information• Accurate goods received information• Which suppliers have not been paid and why

• Co-ordination information• Which receipts have been transferred from Purchase Invoice to Treasurer's Dept. for

payment• Development Information

• Which suppliers are antagonistic to the Company and why• Control information

• The extent to which goods and services provided by suppliers are meeting company quality standards

Step 3. Example of input/output analysis of one section of a Purchase Invoice Dept.This department checks and passes for payment the invoices of firms who supply goods and services tothe Company.

Inputs

Mail Clerks sort invoices

VAT clerks edit invoices

Comp operator check invoices

Invoice is microfilmed

data prep

one copy

Commercial orProduction InvoiceClearance SectionsHere invoices arematched with GRNs

one copy

data prep

Goods Received Notes

Goods receivednotes are batchedand checked

Outputs

DIEB 1.38

ETHICS: Discussion• Common­reaction­to­ETHICS:­it­is­impractical­because­ Unskilled­users­cannot­do­the­design­properly.­ Management­would­never­accept­it.

• To­reaction­1:­Mumford­argues­that­users­can­and­do,­design­properly.­They­need­training­and­help,­but­this­can­be­provided­relatively­easily.­More­importantly,­they­have­the­skills­of­knowing­about­their­own­work­and­system,­and­have­a­stake­in­the­design. 

• To­reaction­2:­Mumford’s­experience­is­that­managers­have­often­welcomed­participation­and­can­be­convinced­of­its­benefits.

• Examples:­ A­group­of­secretaries­at­Imperial­Chemical­Industries­(ICI)­designed­new­

work­systems­for­themselves­in­the­wake­of­the­introduction­of­word-processing­equipment.

­ A­group­of­purchase­clerks­helped­design­a­major­on-line­computer­system.

• The­first­major­use­of­ETHICS­in­the­development­of­a­large­system­was­DECs­XSEL,­an­expert­system­for­their­sales­offices,­used­to­configure­DEC­hardware­systems­for­particular­customers.

DIEB 1.39

Modellering af systembrug

• GOMS­og­Keystroke­er­teknikker­til­modelleringaf­brugen­af­et­system

• De­kan­bruges­i­design

• De­bruges­også­til­evaluering,­hvor­man­”teoretisk”­regner­ud,­hvor­lang­tid­det­tager­at­udføre­en­funktion­–­dette­sammenlignes­så­med­virkelige­observationer

DIEB 1.40

Tre eksempler

• Indlæggelse­af­en­patient­(hospital)

• Kommunikation­i­et­sikkerhedskritisk­domæne­(kraftværk)

• Samarbejde­om­beslutningstagning­i­en­dynamisk­situation­(opmænd)