TRADITIONELLA SYSTEMUTVECKLINGSMETODER (mm)
INFORMATIK 41-45p
TRADITIONELLA METODER
THAIS-metoden
60-talet
Upphovsman: Börje Langefors
Fundamentalprincipen: Man kan arbeta med stora oöverblickbara system. Systemet består av så många delar och relationerna mellan dessa delar är så komplicerade att man inte genast kan få en fullständig överblick över det. Därför måste man först bryta ner totalsystemet i delsystem. Nedbrytningen sker tills man har överskådliga delsystem.
Langefors menar att användaren skall medverka vid utveckling av system.
Langefors menar att data blir information först när någon tolkar datan.
Infologiska ekvationen:
I=i(D;S;t)
| I=Information | Producerad av |
| D=data | Och |
| S=förkunskaper(individens totala livserfarenhet) | Genom tolkningsprocessen |
| i=tolkningsprocessen | Över tiden |
| t=tiden |
Poängen med denna är att olika människor tolkar data på olika sätt.
SIS-RAS-metoden
Slutet av 60-talet
Standardiseringskommissionen I Sverige
Riktlinjer för Administrativ Systemutveckling
Viktiga begrepp: "enhetlighet" i både arbete och dokumentation.
Stegen:
Genomförande: - Målstudie
Informationsstudie
Behandlingsstudie
Systemstudie
Detaljstudie
Systemutförande
Efterstudie
I denna metod lägger man stor vikt vid dokumentationen.
ISAC-modellen (består av både metoder och tekniker)
Mitten av 60-talet
Modellen är rationellt och analytiskt präglad
Den löper parallellt med livscykelmodellen
Den är stark i FA och svag i utformnings- och realiseringsfaserna
Den har ett funktionsorienterat angreppssätt, d v s den utgår från vilka uppgifter (produktion, lager) verksamheten skall utföra och genom detta se vilken information som är nödvändig.
Modellen betonar betydelsen av användarmedverkan men det finns inga detaljerade anvisningar för hur detta skall gå till.
Metodområden:
Förändringsanalys: 1. Analys av nuläget
Systemering: 1. Verksamhetsanalys
Beskrivningstekniker
Grafer
Egenskapstabeller
Processtabeller
| Fördelar | Nackdelar |
| Spridd över hela världen | Svår att förstå |
| Utförlig analys | Tidskrävande |
| Ger en bra dokumentation | Svår att lära |
| Omfattar hela systemutvecklingen | Svag i utformning och realisering |
SASD-modellen
70-talet
Strukturerad Analys/Strukturerad Design
Traditionell modell vilket betyder att:
Först dokumentation sedan revolution
Följer livscykelmodellen
Grafiska beskrivningstekniker
Svårt att få med användarna
De fem stegen
Beskrivningstekniker
DFD – Dataflödesdiagram
DD – Data Dictionary
Processbeskrivning (strukturerat språk för att beskriva hur indata förvandlas till utdata)
Beslutstabeller (vilka förutsättningar som måste vara uppfyllda för att något skall påbörjas)
Angreppssätt
Modellen är precis som ISAC, fuktionsorienterad.
| Fördelar | Nackdelar |
| Lätt att förstå och lära sig | Svårt att se samspelet mellan verksamhet och informationssystemet |
| Visar tydligt vad som skall lagras | Svag i övergången från nuläge till framtid |
| Omfattar hela systemeringen | Inget stöd för nytänkande |
SIMM-metoden
80-talet
Man utgår inte från att en datorlösning är självklar
Man ställer sig 2 viktiga frågor: - Vad beror dagens problem på?
- Vad leder problemen till?
Metodstegen
Om man med detta finner att datorsystem är den bästa lösningen går man vidare med VIBA/SIMM:
Metoden skall betraktas som en "verktygslåda"
Kan användas i såväl det analytiska som det experimentella arbetet i systemutvecklingen.
MBI-metoden
Mitten av 70-talet
Mål Beslut Information
En metod för att praktiskt genomföra verksamhetsanalys
En generell utredningsmetod
3 st skeden:
Syftet med dessa är att peka ut vilka områden som skall förändras.
Beskrivningsteknik:
Delsystem
Informationsutbyte
Lagring
OOS-modellen
Slutet av 80-talet
Den bakomliggande filosofin är att öka abstraktionsgraden genom att man utgår från verkligheten.
Man använder sig till största delen av befintliga metoder/tekniker.
Modellen delas in i: OOAnalys
OODesign
OOProgrammering
Man har ett objekttänkande vilket innebär att företeelser ses som objekt vilka kan ha olika tillstånd (en lampa kan vara tänd/släckt)
Stegen: 1. Tidig analys (ex med MBI)
Dessa utförs iterativt
| Fördelar | Nackdelar |
| Modellen leder till konsekvent dokumentation | Höga initialkostnader eftersom man gör alla "byggstenar" i början |
| (Detta) leder också till enklare underhåll | Det finns en övertro på OOS och det anses trendigt |
| Enklare att engagera användare | Vissa begrepp är svåra att förstå |
| Svårt att se helheten |
SIV – både en modell och metod
Början av 80-talet
Standardsystem I Verksamheter
Grundtankar:
Stärka köparens situation gentemot leverantören.
Har en egen livscykel.
Den tar fasta på det faktum att köparen måste jämföra olika system när han väljer.
Beskrivningsteknik
Fritt men man använder oftast de från ISAC och SASD
SSM är en filosofi + metod = metodologi
60-talet
Soft System Methodology
Helheten är det viktigaste
Vetenskapen är komplex därför är det svårt att få en bild av helheten utifrån de enskilda delarna.
De 7 faserna: 1. Problemsituation (diffus)
Processen är viktigare än resultatet och organisationen kommer att förändras bara av att gå igenom SSM.
ETHICS-modellen
70-talet
Effective Technical and Human Implementation of Computer Systems
Vid systemutveckling måste man ta hänsyn till sociala och organisatoriska aspekter.
Stegen:
Ett brett deltagande är en viktig del av ETHICS. Detta kan ske i form av:
Konsultativ systemutveckling
Representativ systemutveckling
Gemensam systemutveckling
PROTOTYPING/EXPERIMENTELL SYSTEMUTVECKLING
det finns olika typer av prototyping: Användarutveckling, Användarmedverkan
Stegen:
Nu finns det 2 varianter: 1. Slit&släng-prototyp
passar vid: transaktionsorienterade tillämpningar
passar inte vid: ADB-system med stora och omfattande beräkningar
| Fördelar | Nackdelar |
| Kommunikationen underlättas | Dyrt |
| Risk att man fördjupar sig i diskussioner kring obetydliga detaljer |
NIMSAD är en metodologi
Problemlösningsprocessen:
* Problemlösningsfasen: 1. förstå den aktuella situationen
4. definiera problem
* Lösningsfasen: 6. Logisk/konceptuell design
7. fysisk design
* Implementeringsfasen: 8. Implementering
Utvärdering av SASD, ETHICS och SSM
SASD
| Styrkor | Svagheter |
| Dokumentation | Mer inriktad på datan än på människan |
| Visar klart flöden av formella data | Förespråkar användarmedverkan med underlättar ej |
ETHICS
| Styrkor | Svagheter |
| Säger att det är moraliskt riktigt att de som skall använda systemet också är med och utvecklar det | Säger inget om hur designern skall hantera olika värderingar, motiv fördomar mm |
| Länkar tydligt information till aktivitet | Utför vissa steg i en märklig ordning |
| Innefattar en utvärderingsfas |
SSM
| Styrkor | Svagheter |
| Man försöker att undvika att tidigt låsa sig vid problem | Förutsätter att användarna har avsevärda konceptuella och filosofiska färdigheter |
| Kan användas av folk med olika erfarenhet och bakgrund | Innehåller element utan vägledning (ex etik) |
| Påpekar att det finns sociala och politiska faktorer som påverkar arbetet | Saknar utvärderingssteg |
DESIGN AT WORK
Kap 1 (L. Bannon)
From human factors to human actors
Användare är alla som kommer i kontakt med systemet.
Brister i HCI: Användare ses som passiva och idiotförklarade. Kommunikationen mellan användare och experter är dålig.
Han vill se systemutvecklingsarbetet som en:
Kap. 3 (Wynn)
Taking practice seriously
Practice: är vad systemutvecklaren gör i sitt arbete men även det som de framtida användarna gör och deras arbetssituation. Titta på det praktiska arbetet, inte bara se till teorier/principer.
Ta practice på allvar: Hur det fungerar praktiskt på arbetsplatsen. Förståelse mellan användare och designers.
Praktiskt resonerande: Användare resonerar förnuftigt. Tyst kunskap som designers bör ta tillvara.
Problemet med ett vetenskapligt förhållningssätt: Forskare utgår endast från sin egen vetenskapliga bakgrund. Systemutvecklare missar viktig information. Systemutvecklare är för inriktade på teoretiska modeller. System bör vara mer flexibla.
The human operator: Aktivt deltagande från användarna under hela utvecklingsprocessen. Ömsesidig förståelse.
To do & To be: I dag är designers för inriktade på hur man skall vara i stället för hur de skall göra det.
Kap. 4 (Suchman, Trigg)
Understanding practice. Video as a medium for reflection and design
Etnografi: Noggranna studier av aktiviteter och relationer mellan dessa i en komplex social miljö.
Interaktionsanalys: Detaljerad undersökning av interaktionen mellan människor och mellan människor och deras materiella miljö.
Studierna kan vara: - Platsorienterade
Kap. 5 (Holmqvist, Andersen)
Perspectives and design
Dataflödesperspektivet: Definierar ett systems funktion utifrån datasynpunkt
Lingvistiska perspektivet: Utgår från användare som informationskällor.
Koordinatör och instruktör beskriver normativt, hur det "borde vara" medan arbetaren beskriver "hur det är".
Koordinatören har ett birds-eye-perspektiv (åskådare) medan instruktören har ett ants-perspektiv (deltagare).
Sematisk återgivning utgår från användarens beskrivning av arbetet.
Kap. 6 (Bödker, Pedersen)
Arbetsplatskultur
Arbetsplatser är olika. Det tar tid att acklimatisera sig till den kultur som råder på en arbetsplats.
Ett möte kan ses som en ritual där status och makt är viktiga ingridienser (instrumentellt syfte)
Det är viktigt att koordinera verksamheten så att människor kan arbeta i samma riktning.
Observationer och hypoteser presenteras för insiders. Designers får därigenom feedback. Denna process är iterativ.
Insiders och Outsiders närmar sig varandra och på så sätt vidgas synen på verksamheten. Outsidern riskerar dock att bli en insider.
Kap. 7 (Bödker, Greenbaum, Kyng)
Setting the stage for design as action
Gruppsammansättning är viktigt
Family resemblence betyder att gruppen sätts samman så att banden är i det närmaste familjelika. Men även att likheter finns med användarens tidigare arbetsmiljö.
Design by doing: Designers och användare sätter sig in i den andres arbete och på så sätt bygger man upp en förståelse.
Cooperative design: Kunskap som finns hos både användare och designers är viktiga för att lyckat designarbete.
Experiencing the future: Simulera framtida arbetssituationer (prototyping).
Learning and trancendance: Lärandet är viktigt. Grupperna lär av varandra och av problemen.
Kap. 8 (Kensing, Madsen)
Generating visions, Future workshops and metaphorical design
Problem vid systeminförande:
Future workshops: Se visioner i framtiden. Består av:
- Kritikfas
Metaphores: används när deltagarna kört fast
Problem: - tidspress
Kap. 9 (Ehn, Kyng)
Carboard computers, Mocking-it-up or hands-on the future
Hands-on experience: praktisk erfarenhet
Skäl till att använda mock-ups:
Nackdelar:
Attrapper är effektiva eftersom ingen reflekterar över den framtida lösningen.
Används datorer kan det vara svårt att skilja mellan attrapp och slutprodukt.
Kap. 10 (Bödker, Grönaek)
Design in action. From prototyping by demonstration to cooperative prototyping
Prototyper är lämpliga när man behöver avslöja outtalade aspekter av användarnas arbetsuppgifter och när man vill engagera användarna.
Tre kategorier av prototyper och kritik mot dessa:
| Kategori | Kritik |
| Prototypen blir systemet | Svårt att justera |
| Körbar specifikation | Svårt språk vilket gör det svårt för användarna att förstå kravspecifikationen |
| Utforskande prototyp | Svårt för användarna att påverka det nya systemet |
Cooperative prototyping: Användare och designers deltar aktivt i processen utifrån sina egna kvalifikationer.
Kap. 11 (Henderson, Kyng)
There´s no place like home. Continuing design in use
Tre skäl till varför vi måste fortsätta förändra system efter deras initiala design:
"Tailoring": Anpassning, modifierat system. Om modifieringen rör verktyget så rör det sig om en anpassning. Om modifieringen är temporär är det användning.
Tre aktiviteter som förändrar teknologins beteende:
Ett antal sätt att ge support till designfolk:
ARTIKLAR
Ett ämne i, om och för förändring
Göran Goldkuhl
Datautvecklingens filosofi
Bo Göranzon
Första ordningens konsekvenser: Problem av teknisk natur.
Andra ordningens konsekvenser: Problem av psykosocial karaktär (arb.miljö, stress)
Tredje ordningens konsekvenser: Förändringar i yrkeskompetensen.
En central fråga: Är det möjligt att överföra tyst kunskap till ett datasystem.
Påståendekunskap/teoretisk kunskap: Hur högt är Mont Blanc?
Färdighetskunskap/praktisk kunskap: Att spela klarinett
Förtrogenhetskunskap: Hur låter en klarinett?
Designarbetets dolda rationalitet
Erik Stolterman
Designprocessen:
Många skulle säga att den konstnärliga processen inte är en designprocess eftersom den står för ett alltför mekaniskt synsätt. Den sociologiska undersökningen är inte heller en designprocess eftersom syftet inte är att skapa något utan att undersöka.
För att betrakta något som en designprocess måste den vara unik. När den upprepas övergår den till att bli rutin.
Ingengörsprocessen:
Forskningsprocessen:
Den konstnärliga processen: