Uppsummering

Transkript

1 Uppsummering

2 Traditional approach focus is on problems information flow tasks describable skills expert rules individuals rule-based procedures Cooperative approach focus is on situations and break-downs social relationships knowledge tacit skills mutual competencies group interaction experience-based procedures (Greenbaum & Kyng 1991) 2

3 Hard Systems antakelser Virkeligheten er selv et velordnet, stabilt system Systemutviklernes rolle er å avbilde verden sannferdig, konsistent og fullstendig Systemutviklerne studerer verden for å utlede krav Språket er en avbilding av verden, vi må bruke presist, helst formelt, språk (jfr. matematisk informatikk) Hard Systems vurderinger Kraftfull tankemåte Våre beskrivelser er svært fattige Idéen om at det finnes en sann representasjon blandes sammen med forestillingen om at vår representasjon er den sanne 3

4 Soft Systems Vi velger å betrakte noe som et system Vi kan anlegge ulike perspektiver og vil ut fra det komme med ulike Systembetraktninger Fortolkning er viktig, prøve å forstå ulike tankemåter. Det er viktig med flere rike bilder og systemdefinisjoner De ulike betraktningsmåtene skal bringes sammen Soft Systems antakelser Design oppfattes som læring Forskjeller mellom ulike oppfattelser kan håndteres gjennom en læreprosess hvor de ulike synene beskrives og defineres Systemutvikleren blir prosesskonsulent Se Peter Checkland: Soft Systems Methodology 4

5 Dialektikk Ulike perspektiver ses på som uttrykk for konflikter og motsigelser, f.eks. basert på interessekonflikter og maktkamp Konflikter/motsigelser som skyldes misforståelser og uvitenhet kan løses med kommunikasjon og diskusjon Konflikter/motsigelser som skyldes interessemotsetninger kan ikke det, de må løses ved forhandlinger, maktkamp eller revolusjon Det antas normalt at det er en hovedmotsigelse som dominerer bildet Det forhandles og inngås kompromisser Dialektikk antakelser Design er handling Systemutvikleren agerer som intervensjonist og forandrere Hegel, Marx 5

6 Hard, myk og dialektisk systemtenkning OOA &D? Konstruksjon: Problemområdet er veldefinert, applikasjonsområdet er stabilt Top-down tilnærming kan være hensiktsmessig Evolusjon Flere problemer med ulike oppfatninger av problemområdet, aplikasjonsområdet i endring, Rike bilder og prototyping for å prøve ut alternativer Intervensjon Problemområdet ikke definert, applikasjonsområdet preget av konflikter Rike bilder får å identifisere konfliktområder, prototyping med vekt på virkelige situasjoner 6

7 Hva er Participatory Design (brukermedvirkning i design) generelt: deltakelse fra brukere i utvikling av saker som vil påvirke deres liv i systemutvikling: involvering av fremtidige brukere i arbeids-aktiviteter i systemutvikling på måter som gjør det mulig for dem å påvirke beslutninger som vil ha betydning for det resulterende systemet og gjennom det, virksomheten der systemet vil bli brukt 7

8 PD gir Hvorfor Participatory Design? IT-løsninger bedre tilpasset brukernes virksomhet både design og bruk inngår i endringsprosessen mulighet for å bevare brukernes autonomi også på sikt (oversikt, læring) Og: PD-teknikker gir rom for kompleksiteten i brukskonteksten PD søker å forankre krav og behov i kjernevirksomheten arbeid med definisjon av problemet kan gi nye svar og nye problemer flere perspektiver gir bedre og mer innovative designideer 8

9 Methods and techniques document analysis interviews observations thinking aloud workshops dead see scrolls collage etc scenarios prototypes future workshop 9

10 Tone Bratteteig 10 Decide on goals and frameworks Analysis The spiral model (Boehm Risk Risk analysis 1988) Evaluate alternatives Risk evaluations Prototyping Evaluation, Planning Plan next phase Requirements Design Realization Simulations Tests Tests Develop next level product

11 OOA & D Rike bilder Systemdefinisjon FACTOR Analyse av problemområde Analyse av anvendelsesområde ( 11

12 Modellen av problemområdet Anvendelsesområde : Modell Problemområde Modellen er en oppdatert representasjon av situasjonen i problemområdet. Brukere får gjennom modellen informasjon om problemområdet Mathiassen, Munk-Madsen, Nielsen & Stage,

13 13 Application domain The organisation that administrates, monitors, or controls a problem domain Problem domain That part of a context that is adminstrated, monitored or controlled by a system

14 14 Care assistants Civil servants who decides about alarms and services Report performed services Individual infomation Integration/coordination Initiera larm, kommunikation Security alarm/ Centre Communication with the use of the alarm More efficient services Elderly and disabled Their perspective: Feel safe and secure, carere, flexibility, privacy Wants systems adapted to their needs The staffs persepctive Relationship with the care taker, understand local needs, offer excellent services Managements perspective Relatives Responsibility, safe

15 Systemdefinisjon: en kortfattet og presis beskrivelse av en IT-løsning uttrykt i et naturligt språk 15

16 F(unctionality) de systemfunktioner som understöder uppgiften inom användningsområdet A(pplication domain) de delar av en organisation som administrerar, övervakar eller styr ett problemområde C(onditions) T(echnology) O(bjects) R(esponsibility) de villkor under vilka systemet kommer att utvecklas och användas både den teknologi som används för att utveckla systemet och den teknologi på vilken systemet kommer att exekveras de viktigaste objekten i problemområdet systemets övergripande ansvar i förhållande till omgivningen 16

17 Analyse av problemområde 17

18 Objekter Et objekt er en abstraksjon over et konkret fenomen i det problemområdet som IT-systemet skal brukes til å administrere, styre eller overvåke Identitet Må kunne finnes / gjenfinnes Tilstand Statiske egenskaper og verdier Atferd Hendelser som påføres eller utføres av objektet, bl.a. felles hendelser Objekter klassifiseres primært etter sine hendelser 18

19 19 Klasser Klasse: En beskrivelse av en mengde objekter med samme struktur, atferdsdmønster og attributter Fenomener Fysiske ting Personer og roller Organisasjoner Steder Begreper Ressurser Systemer Abstrakter Klasser bil, vare, emballasje, materiale ansatte, forelder, kunde, medlem virksomheter, avdelning, gruppe, prosjekt hylle, parkeringsplass, tomt, by firkant, valuta, kvalitetsparameter, gebyr penger, tid, energi, informasjon gateregister, kassaterminal, alarmsystem avtale, spesifikasjon, forestilling, ekteskap

20 20 Hendelser Hendelse: En øyeblikkelig begivenhet Involverer ett eller flere objekter Atomistisk (udelelig) Observerbare Identifiserbare Eksempler Skrotet, forflyttet, fusjonert, besatt, forstørret, betaling, gate innført, forlenget Valg av hendelser Ut fra hva som er relevant i forhold til systemdefinisjonen Hendelser som bare skjer i datasystemet beskrives ikke

21 21 En struktur hvor en generell klasse beskriver egenskaper og atferdsmønstre som er felles for et antall spesielle klasser Egenskapene og atferdsmønstrene nedarves til de spesielle klassene Er-en (is-a) Avdeling Produksjons avdeling Service avdeling

22 22 Klynger En samling klasser som er innbyrdes forbundne «klynger» Personer Person «klynger» Organisasjonsenhet Avdelning Kunde Ansatt Maskin Produkt

23 23 Relasjoner mellom objekter Tegnes også på klassediagram Fastlegger kardinalitet (dansk: mangfoldighet) Aggregering Associering

24 24 Aggregering En struktur hvor et overordnet objekt (helheten) består av et antall underordnede objekter (delene) Uttrykker at et objekt er en del av et annet, inneholdt i et annet, medlem i et annet Har-en, inngår-i, (has-a, part-of) Helhet-del, sammensetning Genser Erme Bol Hals

25 Associering En struktur hvor et antall sideordnede objekter knyttes til hverandre En bil eies av en eller flere personer, en person eier null eller flere biler Bil Person knows associated with 25

26 26 Hendelsesforløp (event trace) en konkret sekvens av hendelser som et objekt er involvert i gjennom et bestemt tidsrom Atferdsmønster (behavioural pattern) et abstrakt mønster av hendelser som fastlegger de mulige hendelsesforløpene for alle objekter av en klasse struktureres som en algoritme eller et tilstandsdiagram

27 27 Sekvens i atferdsmønstre Regulære uttrykk Hendelse 1 + Hendelse 2 + Hendelse Hendelse n Tilstandsdiagrammer Hendelse 1 Tilstand 1 Hendelse 2 Tilstand 2 Fødsel + Dødsfall Fødsel Levende Dødsfall Død Tilstand 1 Hendelse n

28 28 Seleksjon valg, if Regulære uttrykk Hendelse 1 Hendelse 2 Hendelse 3... Hendelse n Tilstandsdiagrammer Landet Styrtet

29 29 Regulære uttrykk Hendelse 1* (Hendelse 1 + Hendelse 2)* Tilstandsdiagrammer Iterasjon løkke, gjentagelse, while Passasjer gått ombord* (Lettet + Landet)*

30 Analyse av anvendelsesområde 30

31 31 How actors interact with the system Actors and Uses-Cases Actors User s or systems that interact with the target system abstractions Use case A pattern for interaction between the system and actors in the application domain

32 Actor table - example 32 Actors Civil servants Care assistants alarm staff Care taker Mobile system Other Use cases Register person X X X(?) Update person X Delete person X Down load information X Report services performed X X Activate alarm one way connection X Establish a two way connection X Set-off alarm X Present information

33 33 Actor specification - example Care Assistants Goal: An employee who performs social care and services in elderly and disabled people s own homes such as help with showers, medicine, assistants with insulin treatment. Characteristics: The care assistants experiences differs. Example: A larges scale of the care assistants has many years of experiences of care and services. They have none or limited experiences to use IT-system other than mobile telephony. For others the job is temporary since it is easy to get a job in the sector but many of them posses skills to use IT, others have limited of experiences.

34 34 Presentation of information - example Use case: When an alarm is activated by a person a message with an identifier is generated in order to access the persons information, the information is read and presented on the screen in the centre marked with a red flag. Object: person (user), alarm, mobile system Function: read the generated message with its identifier, read the persons information, present the information on a screen

35 35 Statechart diagram - example Identifier registered (who, date, time) Presentation on the screen (who, when, address) Press the alarm Active Dealt with the alarm Establisment of a communication channel (date, time, number)

36 36 Functions Update Signal Read Compute

37 Function types AD I F M AD I F M * * PD * Update PD Signal AD I F M AD I F M * * PD Read PD Compute (I)nterface (F)unction (M)odel * Effect of the processing Initiative 37

38 38 Function list - example Function Complexity Type Register, update, delete a person Normal Update Report performed services Read person/service Activate the alarm Set-off the alarm Present the data of the person who activates the alarm Set up the communication channel Normal Simple Normal Simple Simple Normal Update Read Read, signal Update Read Signal