Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

Kursusgang 1 Oversigt: Kurset Designprocesser Modellering af brugere

Lignende præsentationer


Præsentationer af emnet: "Kursusgang 1 Oversigt: Kurset Designprocesser Modellering af brugere"— Præsentationens transcript:

1 Kursusgang 1 Oversigt: Kurset Designprocesser Modellering af brugere
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

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

3 HCI: Hvorfor er det vigtigt Operatørernes fejl? (1)
Three Mile Island, Harrisburg, Pennsylvania: 28. marts 1979 28/3-79, kl 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

4 HCI: Hvorfor er det vigtigt Operatø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

5 En anden forklaring på hvorfor operatørerne lavede fejl
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. 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

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 Withdrawal Use 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

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

8 Problemstillinger: HCI som disciplin (2)
ACM komite til design af HCI-uddannelser (1992) Se supplerende litteratur på spiseseddel DIEB

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): Videregående HCI-metode Værktøjer og biblioteker til implementering af brugergrænseflader Grundlæggende HCI-begreber og brugbarhedstest (kun Dat1) Programmering af brugergrænseflader (kun Inf1) Evaluering Evalueres gennem projektet. DIEB

10 Spiseseddel To versioner af Dix Fokus på de væsentlige afsnit DIEB

11 Designprocesser Vandfaldsmodellen Prototyping
Specifikation eller prototype Spiralmodellen DIEB

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

13 Vandfaldsmodellen i Dix
Svarer til den generelle vandfaldsmodel Lidt andre navne på faserne Requirements specification Operation and maintenance Architectural design Detailed design Coding and unit testing Integration and testing DIEB

14 Relation til OOA&D Requirements specification Architectural design
Operation and maintenance Architectural design Detailed design Coding and unit testing Integration and testing DIEB

15 Erfaringer med vandfaldsmodellen
Projektledelse er simpelt: Hvorfor? Virker ikke i praksis! Tænk på et af jeres tidligere projekter som eksempel DIEB

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

17 Problemer med vandfaldsmodellen
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

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 dirty Early implementation without prior analysis and design. Revised until the users are satisfied. Revisions become complicated and maintenance is very expensive. Throw-away Development in order to enquire into and express requirements. Is often described as a ”running” requirements specification. Design-driven An 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-up A cardboard or similar non-executable model of the system. Evolutionary A modifiable, running model of part of a system. Is gradyally developed into the final version which becomes the system. DIEB

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

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

21 Kontingensfaktorer Quantity Too much Too little
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

22 En simpel kontingenmodel
Reference: Burns & Dennis DIEB

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

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

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

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

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

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

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

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 DIEB

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

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

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

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

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

36 Alternativ ETHICS: 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. DIEB

37 ETHICS: Methodology Why Change? System boundaries
Description of the existing system (5 different levels, operative tasks to whole system) Definition of key objectives Definition of key tasks Definition of key information needs Diagnosis of efficiency needs Diagnosis of job satisfaction needs Future analysis Specifying and weighting efficiency and job satisfaction needs and objectives The organisational design of the new system Technical options The preparation of a detailed job design Implementation 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 DIEB

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

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

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) DIEB


Download ppt "Kursusgang 1 Oversigt: Kurset Designprocesser Modellering af brugere"

Lignende præsentationer


Annoncer fra Google