Designaspekter på modellutveckling och metametodik Björn Banck, Christina Amcoff Nyström Mitthögskolan/Umeå Universitet Institutionen för Informatik 831 25 Östersund http://www.itk.mh.se Fax: +63-165505, email: bjorn.banck@itk.mh.se christina.amcoff@itk.mh.se Abstrakt Författarna har valt att applicera olika aspekter inom design på en modell för att utföra grovdesign av informationssystem. Det är inte författarnas ambition i detta skede att ta fram en fullständig modell, utan snarare att beskriva viktiga aspekter, ställningstaganden och ett förslag till en första utgångsmodell, för att i ett senare skede konstruera densamma. En del av denna modell innehåller en metametod för att välja specifik metod utifrån vilken typ av informationssystem det gäller samt den specifika situationen. Vi har lagt fokus på identifikation av goda designkriterier generellt för systemutveckling, aspekter på design av en första utgångsmodell för de inledande stegen vid utveckling av informationssystem samt aspekter på design av urvalskriterier (metametod) som beroende på det specifika informationssystemet, skall kunna utmynna i val av konkreta metodsteg befintliga eller i behov av konstruktion. Dessa urvalskriterier skall kunna karaktärisera olika typer av informationssystem. Utgångsmodellen skall efter test och ev. modifikation kunna fungera som en generell modell vid de inledande stegen i systemutveckling. Valet av metodsteg som utförs med hjälp av vår metametod befintliga eller i behov av konstruktion är knutna till en virtuell verktygslåda som också kommer att behandlas översiktligt. Vid fortsatt arbete kommer vi att fokusera modell och metametod på intranät vid vidareutveckling, test och modifikation. Nyckelord: design, kreativitet, modell, designkriterier, metametod
1 Introduktion Behovet av designtänkande och designmetodik inom systemutveckling är väl idag inte speciellt omtvistat. Flera forskare och yrkesverksamma inom området är nog överens om betydelsen av en god och genomtänkt design av ett informationssystem. Detta är tyvärr inte detsamma som att alla system som används idag är väl designade. Van Gigch (1991) menar bland annat att allför många åtgärder avseende informationssystem är analytiska och leder i bästa fall bara till förbättringar inom de ramar som man tror sig verka inom. Informationssystemets syfte, struktur och funktioner ifrågasätts inte. En designprocess på hög nivå skulle kunna åtgärda detta (ibid.). Då nya tillämpningsdomäner kommer till och befintliga förändras så ökar också behovet av att utveckla designmetodiken. Informationssystem används för att lösa och stödja nya arbetsuppgifter vilket ställer krav på ny designmetodik (Warfield, 1990). Tillgången till ny och förbättrad teknik torde också ställa krav på förändrad designmetodik som nyttjar de möjligheter som finns. Utveckling och etablering av kreativa miljöer a la Warfields Demosophia borde vara angelägna projekt (ibid.). Design är ett idag ofta använt begrepp. Vad är då design och vad är resultatet av designarbete? Någon entydig definition torde inte gå att finna. Stolterman (1991 sid. 9) definierar design enligt följande: Design är att uppfinna, välja, utveckla, utforma och bestämma ett någots funktioner, egenskaper, utseende, uppförande, möjligheter och begränsningar. Designprocess definierar Stolterman (ibid. sid. 13) som: Designprocess är benämningen på det arbete som måste utföras för att det i en designsituation ska kunna uppstå en produkt Simon menar att design sysslar med hur saker borde vara genom att skapa artefakter för att nå uppsatta mål (Simon, 1998). Warfield (1990) har identifierat några viktiga aktiviteter i designarbetet : - Konceptualisering - Val - Dokumentation Operationer under detta arbete är - Generera idéer - Klargöra idéer - Strukturera idéer - Förklara strukturen - Förbättra idéer Inom systemutveckling så är webbdesigners åtminstone framtill i skrivande stund en växande och aktuell yrkeskategori. Det är egentligen ganska talande att benämningen designer egentligen först genom webbdesigners blivit en vedertagen benämning för en yrkeskategori inom systemutveckling. Design av informationssystem görs, enligt vårt sätt att se, på flera olika nivåer inom ett systemutvecklingsprojekt. Ibland är det design på hög nivå som avses, exempelvis en design av informationssystemets målsättning och roll i en verksamhet och ibland är det en design av exempelvis användargränssnitt. Vi menar alltså att design av informationssystem inte är liktydigt med design av enskilda Webbsidor t ex, utan är något
mycket mera. Behovet av en genomtänkt design och designmetodik är kanske som allra störst på högre nivåer. Van Gigch (1991) menar att informationssystem i regel stagnerar på en mekanisk nivå och inte utnyttjas som ett levande system. Detta arbete behandlar dels vår syn på design och behovet av god design inom systemutveckling, samt behovet av utveckling av designmetodik och stöd för val av metodik. 1.1 God design inom systemutveckling. Då vi anser att designtänkande och designkunnande är av yttersta vikt vid systemutveckling tar vi upp detta i ett separat avsnitt i arbetet. Nedan följer några för oss viktiga frågeställningar som vi kommer att vidareutveckla längre fram i arbetet. - Finns det något som kan kallas "god design" inom systemutveckling. Går det urskilja allmängiltiga designregler som gäller oavsett designsituationen? - Kan man lära sig god design. Är designförmåga något medfött eller borde systemutvecklare få utbildning inom området? - Finns det kunskap att hämta från andra discipliner (arkitektur, produktdesign mm)? - Är metodanvändande något önskvärt inom design. Hämnar metodik kreativitet? 1.2 Behov av metodutveckling En av våra utgångspunkter för detta arbete är att de metoder som finns och används idag inte svara mot de aktuella behoven. Tidigare informationssystem ersatte ofta en tidigare manuell arbetsuppgift och hade bland annat nedanstående egenskaper: - Löste en enskild arbetsuppgift - Homogena och kända användare - Ganska statiska. Hade ingen inbyggd dynamik - Byggdes från noll - Samverkade med ett fåtal andra system De metoder som användes (används) var lösningsorienterade och cementerade gamla, kanske inte önskvärda arbetssätt och strukturer. Metoderna var också många gånger ganska komplicerade och försvårade därmed användarmedverkan. Dagens och framtidens informationssystem är av en helt annan karaktär och har därmed andra egenskaper: - Krav på dynamik och ständig förändring - Samverkan med verksamhetens mål o strategier - Krav på användarmedverkan vid utveckling av system - Samverkar med många andra informationssystem - Heterogena och ibland okända användare - Nya tekniska möjligheter (grafik och kommunikation) - Krav och behov av individualisering av till exempel gränssnittet
Då vi menar att kvaliteten på informationssystem i hög grad grundläggs i det tidiga designarbetet presenteras ett förslag till arbetsgång (modell) i detta arbete. En viktig del är att utforma en grovdesign som bland annat skall ligga till grund för val av fortsatta metoder. 2 Modell för grovdesign 2.1 Design av ny utvecklingsmetodik Nedanstående modell är de arbetssteg som av flera metodutvecklare använts för att skapa ny metodik. Arbetsstegen förklaras kortfattat nedan. 1 2 5 6 3 4 8 7 Figur 1 Modell för design av ny utvecklingsmetodik 1) Analys av befintliga metoder 2) Gemensamma drag hos befintliga metoder (kärna) 3) Analys designsituationer särdrag, olika saker att ta ställning till (teknikmognad, åldersstruktur befintliga lösningar, kunder, nisch, policy) 4) Krav som bör överföras till ny metod (eg. modell) 5) Brister (saker som inte finns) 6) Ny Metod 7) Tillämpning (fallstudier, aktionsforskning) 8) Modifikation 2.1.1 Modell för utveckling av grovdesign Vi har anpassat figur 1 så att den kan ligga till grund för vårt fortsatta arbete. Den visar vår arbetsgång för att utveckla i första hand en modell för det tidiga designarbetet. (grovdesign)
Nedanstående modell är en förstoring av steg 1-6 i den generella modellen ovan. 1. 5 6 7.. 2 3 4 Figur 2 Vår modell för utveckling av metodik för grovdesign 1. Befintliga metoder 2. En analys av vilka krav som ställs på dagen och framtidens informationssystem I vilken omgivning och vilka verksamheter skall informationssystem verka och stödja 3. Designkriterier för god design 4. Principer och utgångspunkter vid systemutveckling 5. Gemensamma drag i befintlig metodik 6. Brister (saker som inte finns) 7. Ny ideal grovdesign 2.2 Designkriterier för god design I detta avsnitt diskuterar vi kring våra synpunkter på god design. Dessa kriterier tycker vi är viktiga att ta hänsyn till vid utformning av vår modell. Detta skall då avspegla sig i metodsteg, principer och arbetssätt etc. i vårt förslag till modell för grovdesign. Genom att lyfta ut designkriterier från övriga viktiga principer och utgångspunkter vid systemutveckling, vill vi markera vikten av designtänkande i systemutveckling. Flera av de punkter vi tar upp skulle kunna tas upp under båda rubrikerna. 2.2.1 Designkunskap Författarna är av den åsikten att det finns s k generell designkunskap om man med detta avser design top-down där helhet, omgivning och mål/strategier först sätts i fokus för att därefter
relatera underliggande system till det större,. Denna generella designkunskap borde vara nödvändig och allmängiltig oavsett vilken situation designern hamnar i. Om vi följer van Gigch (1990) rekommendationer och modellerar uppifrån, torde det finnas vissa gemensamma särdrag oavsett designsituation. Utifrån utfallet av denna första metamodellering, borde det däremot finnas ett antal metoder som är mer eller mindre lämpliga för den situation som skall modelleras på den undre nivån. Varje designsituation är unik, men de kan ha liknande drag eller principer som skall identifieras. Vi tror inte att det existerar metoder som täcker alla möjliga designsituationer utan designern kommer från fall till fall att få avgöra om det finns lämplig metod, om det finns lämpliga metoddelar som går att kombinera ihop d v s situationsanpassa och skräddarsy en metod för det specifika designtillfället. Designern måste alltså besitta specifik designkunskap utifrån den givna situationen. Vi lägger alltså stor vikt vid designern, hans roll i designprocessen och hans designförmåga. Aspekter på designförmåga kan vara; rationellt handlande som bidrar till hög kreativitet, visualisering och abstraktion, estetik och ideal (Stolterman, 1991. Sid. 96). Dessa aspekter går inte att formalisera till en metod utan vi anser att metoder mer skall stödja själva designförmåga höja kreativitet, underlätta abstraktioner etc. En designer behöver en övergripande metod för att veta hur han på ett målmedvetet sätt kan gå tillväga för att utveckla sina ideal, sina tankefigurer, sin kreativitet och sin estetik. (ibid. sid. 97). En designer bör i ett idealorienterat perspektiv utveckla tankefigurer och en estetik. Han bör vidare medvetet studera sina egna och andras handlingar för att lära sig och få öka erfarenhet. Detta kräver ett reflekterat tänkande jämför Donald Schöns (1983) reflektionerande praktiker. 2.2.2 Designsituationer Definition enligt Stolterman (1991, sid. 13): Designsituation: En designsituation är den omgivning som både är upphovet till att en viss designprocess utförs, samt den situation vari denna designprocess utförs. Denna situation kan anta en mängd olika skepnader. Ibland initieras den designprocess genom att någon ser problem eller möjligheter, ibland genom att någon beställer (köper) utförandet av en process. Detta är mycket vanligt vid systemutveckling. Ett företag betalar interna eller externa konsulter att utföra en designprocess. I detta fall utgör företagets verksamhet och förutsättningar, beställarnas idéer, krav och önskemål, samt övriga förutsättningar en typisk designsituation. I andra fall, till exempel när en konstnär skall skapa ett konstverk, kan situationen vara konstnärens egen verksamhet, hans beslut att skapa och de förutsättningar som han lever under. Det finns en mängd olika designsituationer som en designer har att hantera. Detta är alltifrån traditionell systemutveckling nyutveckling, förbättring av existerande system till redesign, organisationsutveckling mm. Modellers innehåll, fasindelning och därtill knutet arbetssätt samt tillhörande metametod(-er) skall kunna hantera och täcka olika typer av designsituationer. Den specifika situationen som designern har att hantera, avgör vilka delmetoder och beskrivningstekniker som designern väljer för att skräddarsy metoden i fasen val av metod som bör vara ett steg i grovdesign.
2.2.3 Miljö och datorstöd vid systemutveckling. En kreativ miljö som stöder gruppkommunikation och befrämjar olika arbetssätt både geografiskt spridda och samlade skall etableras. Det skall finnas möjlighet att på ett enkelt sätt anpassa miljön till olika typer av grupper - miljön skall vara flexibel. Warfield (1990) beskriver en miljö som han kallar Demosophia (wisdom of the people). Beträffande begreppet demosophia så förekommer det inom flera discipliner. Vid sökning på Internet visar det sig att syftet med ett demosophia verkar vara att designa sociala system på ett demokratiskt sätt. J N Warfield (1990, sid. 266), använder det i betydelsen av en speciellt utformad laborationsmiljö som skall stödja design. Detta bygger Warfield på Harold Lasswells vision om fysiska faciliteter som decision seminar room och social planetarium (ibid., sid. 275). Viktiga faktorer i designen av ett "Demosophia" är enligt Warfield; fysisk komfort, rymliga och flexibla arbetsytor, stöd för multipla roller bland deltagarna, goda displayutrymmen, stöd till kontinuerlig datalagring, videofilmning, datorstöd, kommunikationsfaciliteter mm. Beträffande datorstöd skall detta stödja kommunikation och idéutbyte oberoende av närvaro i rummet. En gemensam whiteboard där deltagare på spridda platser tillsammans simultant kan skissa på idéer och lösningsförslag bör ingå i designmiljön. Tekniken skall stödja såväl dokumentation som återanvändning av delresultat. CASEprogram som används måste vara relativt öppna då de skall stödja en mängd olika systemeringssituationer och faser. De skall fungera som en verktygslåda med ett skal till vilket val av moduler knyts. CASE-program skall vara en kombination av funktonalitet från traditionella applikationer som ritprogram, ordbehandlare, kalkylprogram etc. samt specifika moduler som stöder t ex idégenerering, rich-pictures (sambandsskisser), arkitekturritningar mm. Vissa av dessa moduler kan vara som delar av CASE-program ser ut idag t ex vanliga datamodelleringsstöd där symboler för detta finns och syntaxkontroll finns. Andra moduler skall kanske innehålla samma symboluppsättningar som traditionella CASE-program, men också tillåta fria symboler, egenkonstruerande symboler samt att syntaxkontroll kan programmeras in där så önskas. CASE-program stöder dokumentation som skall kunna skräddarsys i fråga om utskriftsformat, upplägg mm. Vidare skall det erbjudas utvecklingsmiljö där utveckling och resultat kan synas i samma skärmbild. På detta sätt går även prototyping snabbare. Verktyget skall även stödja jämförelse av olika alternativa designförslag. Detta kan vara någon typ av syntaktiskt jämförelse där parametrar skall kunna anges och viktas för att jämförelse skall kunna genomföras. 2.2.4 Systemutveckling och kontinuerligt lärande Kan man lära sig god design och kreativitet eller är det något medfött? Vi tror att det till viss del kan vara medfött. Vissa människor kan från barnsben vara väldigt uppfinningsrika, utan begränsningar i sitt tänkande och upplevas som udda av omgivningen. Vad detta beror på vet vi inte. Beträffande utvecklingsbarheten så kan man med användandet och utlärning av befintliga processtekniker som brainstorming, braindrawing etc., göra ett utvecklingsarbete roligare. Om personer har roligt när de arbetar, släpper man ofta också loss från traditionella låsningar. Ett annat sätt kan vara övningar i metafortänkande. Mycket av det här går ut på lateralt tänkande där man växlar mellan olika motpoler; på ett kreativt sätt väljer bästa lösningar, genererar nya idéer mm. Ett exempel kan vara att två grupper skall lösa en given uppgift. Detta kan vara allt från en värdering av lösningar till genering av olika idéer. Den ena gruppen utbildas och övas i t ex lateralt tänkande (six-thinking-hats vid värdering t ex) enligt de Bono (ibid.). Den andra gruppen, löser uppgiften enligt vad gruppen själv bestämmer
(troligtvis traditionell diskussion med val i form av majoritetsbeslut). Resultaten jämförs och grupperna presenterar motiven till vald strategi i lösningen. Detta bör upprepas med en mängd olika typer av uppgifter och kreativa tekniker. Behöver vi öka vår kunskap om design? Inledningsvis skall förtydligas att vår i frågeställningen, här tolkas som alla inblandade i en designsituation användare, designers, blivande designers och så vidare. Om vi börjar med blivande designers, konstaterar vi att svaret självklart är ja. Detta grundar vi på att design inte kan ses som ett isolerat fenomen utan att sammankopplas med begrepp som kvalitet och kreativitet. Om vi då tittar på dagens utbildning av t ex systemvetare, ser vi att mycket behöver göras för att förmedla och ge insikt om t ex olika kreativitetshöjande tekniker, lateralt tänkande ( lateral thinking which treats creativity as the behaviour of information in a self-organising information system - such as the neural networks in the brain. From such a consideration arise the deliberate and formal tools of lateral thinking, parallel thinking etc.") (de Bono, 2001), perceptionella blockeringar mm. Vi behöver alltså öka studenternas kunskaper i detta. Vidare sker designaktiviteter i en viss miljö och denna bör då stödja kreativt tänkande. Etablerande och utveckling av laboratorium á la Warfields Demosophia borde här vara aktuell (Warfield, 1990). Om vi tolkar frågan som att vår är forskare inom informatik och systemvetenskap så är frågan inte lika lätt att besvara. Själv vet vi (naturligt nog) inte allt som är nedpräntat om design och designvetenskap. Om vi däremot relaterar frågeställningen till det konstaterande att domäner tillkommer och förändras och att vår syn på världen kontinuerligt omprövas och ändras, så är det nog naturligt att design i sig också torde behöva vidareutvecklas. Vidare måste vi vara öppna såtillvida att vi studerar andra vetenskaper och discipliner som använder sig av design, för att förstå vad som händer där och hur deras designsyn ser ut och utvecklas. Sådana discipliner kan t ex vara arkitektur, produktdesign etc. Förändringsarbete och systemutveckling är en läroprocess, både för designers och blivande användare. Metoddelar och beskrivningstekniker som utvecklas, bör i hög grad vara självförklarande och lätta att använda Ett högt engagemang skall eftersträvas där partssammansatta arbetsgrupper arbetar tillsammans. 2.2.5 Arbetssättet i systemutvecklingsprocessen. De aktiviteter som ingår i design är bland andra konceptualisering, val och dokumentation (Warfield, 1990). Operationer knutna till dessa aktiviteter är att generera idéer, klargöra dessa, strukturera dem, förklara dem samt välja de rätta idéerna (ibid.). Som stöd för dessa aktiviteter och därtill hörande operationer skall ett kreativt, engagerande och kvalitativt arbetssätt väljas. Design är inte ett begrepp som står isolerat utan vid sökning på Internet kopplas begreppet ofta samman med kreativitet. Både individuell och gruppkreativitet skall stödjas och underlättas. Gruppkreativitet kan befrämjas genom t ex. att arbetsgrupper formerar sig på liknande sätt som Stafford Beer (1994) förespråkar genom Team Syntegrity. Det finns en mängd olika verktyg som går att använda i de olika faserna vid systemutvecklingen och som stöder kreativitet. Hit kan nämnas användandet av metaforer och förebilder för att komma bort från låsningar Dessa verktyg bidrar både till individuell och gruppkreativitet. (Hägerfors, 1995). Vidare är det viktigt att kunna växla mellan olika perspektiv vid designen; helhet delar, möjligheter begränsningar, fantasi verklighet, improvisation metodik, intuition kunskap, abstrakt konkret, indikationer klarhet (Lerdahl, 1997). Vid generering av idéer och val av idéer rekommenderas arbetstekniker som brainstorming, braindrawing,
six-thinking-hats, djävulens advokat mm att användas. Dessa tekniker stöder lateralt tänkande och bidrar till ökad mångfald (de Bono, 2001). Prototyping rekommenderas som arbetsform i ett tidigt skede av systemutvecklingen då det är önskvärt att för intressenter kunna presentera visuella och snabba resultat. Snabba delresultat är också önskvärda i och med att teknikutvecklingen accelererar och därmed kravet på den totala utvecklingstiden. Prototyping är också ett exempel (!) på exempeltänkande där detta kan vara att föredra (eller vara ett komplement) framför abstraktioner av det blivande systemet (Stolterman, 1991. sid. 45). 2.3 Principer och utgångspunkter vid systemutveckling Här redogör vi för de principer och utgångspunkter vi tycker är viktiga vid arbetet med att utveckla informationssystem. Dessa tillsammans med designkriterierna är grunden till vårt förslag till modell. Det är viktigt att det synsätt som förespråkas är tydliggjorda och avspeglar sig i förslag till modell.. 2.3.1 Bakomliggande antaganden skall synliggöras Modeller och metoder som utvecklas skall presenteras och genomsyras av de bakomliggande antaganden (Stolterman, 1991) och utgångspunkter som dessa vilar på. 2.3.2 Metoder och Metametodik För att eftersträva att användare, intressenter och designers upplever metodanvändandet som frigörande skall metametodik användas för att skräddarsy och plocka ihop skräddarsydda metoder givet viss situation. Författarna ifrågasätter användandet av en genomgående metod då det finns en fara i att en given metods användande, lurar deltagarna i systemutvecklingsarbetet att slaviskt följa givna metodsteg utan att ifrågasätta syfte och resultat av dessa (Feyerabend, 1993, Lerdahl, 1997). Feyerabend (1993, sid. 14) hävdar att några av de genom tiderna största upptäckterna uppstod enbart därför att vissa tänkare antingen beslutat sig för att inte ta hänsyn till metodologiska regler, eller därför att de omedvetet bröt mot dessa. Feyerabend menar att metoder måste sättas in i ett tidsperspektiv och att de åldras och att det alltid finns omständigheter när det är tillrådligt att inte bara ignorera regler, utan även att anta en motsatt ståndpunkt. Detta gäller främst hypotesprövning. Att göra sådana avsteg från någon slags normal praxis, är absolut nödvändigt för att kunskap skall växa (ibid.) Även Erik Stolterman (1991) har i sin doktorsavhandling konstaterat det paradoxala med metodanvändande: Systemutvecklarna visar mycket tydligt att de egenskaper som de själva anser viktiga för en skicklig systemutvecklaren, inte är egenskaper som stöds av metoderna. En anledning kan vara att dessa egenskaper traditionellt ses som diffusa. Varken den analytiska eller den kreativa förmågan än något som vanligtvis betraktas som möjlig att styra eller stödja i någon större grad. Vi får på så sätt metoder som för utövarna inte känns naturliga, eftersom de inte behandlar aspekter av designprocessen som de själva upplever som viktiga. (ibid. sid. 153).
2.3.3 Demokratiskt systemutvecklingsarbete Systemutvecklingsarbetet skall ske på ett demokratiskt sätt. Enligt Robert Flood (1995, sid. 20) så innebär design av organisationsprocessen, att om fokus sätts på möjliga funktioner och hur dessa kontrolleras och samverkar, så "lyfter sig" designern över etablerade maktstrukturer. Flood påpekar även vikten av att analysera individuella och kulturella skillnader och likheter. Om vi tar hänsyn till processer (flöden), design (funktioner) kultur (beteende, sociala roller och praktik) samt politik inom en organisation kan makt spridas på ett helt annat sätt än det traditionella (ibid., sid. 21). 2.3.4 Strävan efter ett idealt tillstånd Systemutvecklingsresultatet skall präglas av en strävan att nå ett så idealt tillstånd som resurser, omständigheter etc. medger. Motiv till detta, är främst att ansatser som strävar efter ideala tillstånd, i regel genererar bättre resultat än t ex problemorienterade dito. Detta kan också relateras till att designern bör gå från funktionsorientering till en estetisk orientering (Stolterman, 1991). En funktion kan se ut på flera olika sätt, men lösa samma uppgift. I detta fall kommer vi att välja funktion utifrån någon typ av kriterier estetik det är alltså andra avgöranden än traditionella som sätts i fokus. Den estetiska dimensionen är en del av att arbetssätt (scenarioteknik, brainstormingbeskrivningar, 2.3.5 Viktigt med helhet och sammanhang Designarbete och metodutveckling skall ta hänsyn till helhet och sammanhang och inte som tidigare enbart avgränsade till detaljer på låg (operativ) nivå (Warfield, 1994). För att inte tappa helhetsbild och omgivningen betydelse, måste modellering starta på den högsta nivån (intelligent system). Detta kallar van Gigch (1991) metamodellering. Han hävdar även att många system stannar på den lägsta nivån (den mekaniska) och blir därefter (löser kortsiktiga, operativa problem i bästa fall). Detta pekar även på att metodutveckling och metodanvändning måste börja uppifrån. Behovet av abstraheringar och generaliseringar har också ökat vilket skulle stödjas av ett arbetssätt med en metamodell som utgångspunkt (ibid.). 2.3.6 Generell modell Det finns generella drag i det inledande arbetet med systemutveckling, oavsett vilken typ av systemutveckling det är. En gemensam modell som täcker de viktigaste frågeställningarna skall kunna täcka nulägesbeskrivning, huvudproblem, visioner etc oavsett vilken typ av lösning som eftersöks. Dock finns det skillnader mellan olika typer av informationssystem vad avser design och utformning av dessa. Familjer av informationssystem har olika karaktäristika och dessa kommer att styra valet av specifik metod för det aktuella, specifika informationssystemet. Därför rekommenderas en generell metod/modell som täcker de inledande stegen i systemutvecklingen (grovdesign) och som ett delsteg i denna, en metametoddel där utifrån särdragen av given typ av informationssystem samt det specifika informationssystemet, tillämpliga metoddelar, beskrivningstekniker och verktyg väljs. Stor vikt bör därför läggas vid karaktäriseringen av olika typer av informationssystem (GIS, intranät, ledningssystem m fl.).
2.3.7 Teknikfilosofi En gemensam teknikfilosofi måste etableras innan det egentliga förändringsarbetet sker. Samtliga involverade skall ha en insikt i andras förväntningar på företagets IT, den policy som skall gälla för IT samt det faktiska användandet för att utifrån detta revidera teknikuppfattningen och gemensamgöra tekniksynen/teknikfilosofin. Nedanstående modell är hämtad från ett seminarium i Umeå (6-7 november 2000) där Erik Stolterman presenterade en modell/teori för att identifiera och tydliggöra teknikfilosofi. Teknik policy Föreställning Användning Figur 3 Modell/teori med aspekter på teknikfilosofi (Stolterman, 6-7/11, 2000) Alla tre bubblorna är dynamiskt beroende. Föreställningen om teknik (vad det är, används till etc.) är varierande och påverkar både teknik och användning. T ex om någon föreställer sig att en viss teknik INTE kan användas till ett visst ändamål, så begränsar detta användningen. Andras användning kan också påverka den egna föreställningen om användning (och därmed även tekniken). 2.3.8 Övriga utgångspunkter och viktiga principer Omvärldsanalyser ifråga om ny teknik, trender, konkurrenter, nya nischer, utveckling, informationsförsörjning mm skall ingå som en viktig del Riskanalys bör ingå vid allt systemutvecklingsarbete. Detta då konsekvenser av s k systems failure blir allvarligare och allvarligare i och med vårt ökade teknikberoende (Warfield, 1994). Arbetet skall utgå från företagets mål och strategier som kontinuerligt skall prövas. Allt förändringsarbete måste kopplas till företagets långsiktiga mål och de strategier som finns. Arbetet skall präglas av ett möjlighetstänkande mer än ett problemorienterat perspektiv. Detta för att lösningsförslag skall formuleras mer hållbara och innovativa. Ett helt problemorienterat synsätt tenderar mer att bara lösa problem.
Kommunikationskanaler (intra och extra) skall analyseras och kontinuerligt uppdateras. Stor vikt läggs vid uppföljning av befintliga kanalerna. Organisationsfrågor måste ingå då systemutveckling rör både system, organisation och personal. Berörda intressenter måste identifieras både inom och utom företaget. Varje systemutvecklingssituation är delvis unik och därför skall som sista fas i grovdesign, val av metod(-delar) ske utifrån de karaktäristika som aktuell informationssystem har, samt det specifika informationssystemet som skall utvecklas. Denna fas kan ses som en metametod för att utföra design av specifik metod i den givna situationen. 2.4 Design av modell för grovdesign innehållande metametod med urvalskriterier för val av specifika metodsteg I detta avsnitt redogör författarna för ett förslag till modell för grovdesign. Denna modell är inte färdig utan skall ses som ett förslag som kan ligga till grund för fortsatt arbete. Vi vill också påpeka att modellen inte skall tolkas som en vattenfallsmodell. Innehållet i designkriterier och principer och utgångspunkter skall prägla arbetet i modellen. De metoder mm som används skall väljas och utformas enligt de principer som finns där. Det är också viktigt att de förutsättningar och principer som gäller är tydliggjorda för de som är inblandade i arbetet. Syftet med grovdesignen är: - Att ta fram en utförlig beskrivning av det tänkta systemet (ideal design) och hur det skall samverka med och stödja verksamheten. - Att utifrån den ideala designen, med stöd av en metametod, göra det framtida metodvalet Designkriterier Principer och utgångspunkter Metametod Designsituation Mål och Strategier P L A N Analys av verksamhet utifrån vision och möjlig- Ideal heter design Analys karaktär hos IS val av spec. metod G R O V D E S I G N Situatiosanpassad metod
Designsituation (specifik situation. Viktigt att här studera de speciella betingelser som råder inom aktuell verksamhet. En omvärldsanalys bör göras, helst med en framskrivning i tiden. Hur ser den miljö ut som verksamheten skall verka i de närmsta åren? Den egna verksamheten och dess relation till andra verksamheter inom organisation bör också studeras. Vilka andra förändringar är att vänta? Vidare bör intressenter analyseras som grupp(-er) avseende förändringsvilja, teknikmognad etc. Den specifika situationen berör allt från företagets storlek, omvärldsanalys, förändringsvilja, befintlig hård- och mjukvara till behov, önskemål och visioner. Förändringen skall också positioneras inom företaget. En första grovdesign utförs där förändringen synliggörs. Designen kan väl utföras i form av rich picture eller motsvarande. Analys av mål och strategier; Företagets mål och strategier ses över och relateras till de lokala mål och strategier som skall gälla inom den del där förändring skall ske (ledningsfilosofi, teknikfilosofi, beslutsordningar, organisationsstruktur, långsiktiga mål och strategier samt operativa dito). Här tydliggörs också de antaganden och förutsättningar som skall gälla för förändringen och fortsatt arbete. Planering; Det fortsatta arbetet måste planeras genom att arbetet skall bemannas (analys kompetensbehov, användarmedverkan fastställas mm), arbetssätt väljas (scenarioteknik, brainstormingmetodik etc hämtas från verktygslådan) och miljö bestämmas och utformas (utrustning, lokaler, behov av kommunikation, anslagstavlor lokalt eller geografiskt spritt). Analys av verksamheten utifrån vision och möjligheter samt framtagande av Ideal design; Visioner och möjlighetstänkande skal prägla den analys av verksamheten som här utförs. Detta skall självklart vila på de mål och strategier som tidigare genomlysts. Här detaljeras en del av det som gjordes i designsituationen (rich picture el dylikt). Den framtida verksamheten med aktuellt informationssystem analyseras och beskrivs. Önskvärd funktionalitet med gränssnitt etc tas fram. Prototyping är en av flera tänkbara metoder här. Det är viktigt att de metoder som används gynnar kreativiteten och möjliggör reell användarmedverkan. Alternativa förslag till förändringar genereras, analyseras och diskuteras. Förslag till förändringar prioriteras med motiv och ev. åtgärdslista tas fram. En första systemdesign (utifrån val) utförs som grundar sig på hur det borde se ut idealt. Detta arbete pågår parallellt med analys av verksamheten. Systemdesignen bortser i det här läget från låsningar till specifika lösningar. Resultatet överförs till metametodsdelen där utifrån de karaktäristika som kännetecknar aktuellt IS, designen kompletteras med förfinade detaljer. Metametod. Analys karaktär hos IS (urvalskriterier); Syftet med det här steget är att beskriva de karaktäristika som kännetecknar olika typer av IS samt ge stöd till framtida metodval. Det finns ett antal urvalskriterier som är gemensamma oavsett vilken typ av IS det är frågan om. Nedan följer några tänkbara karaktäristika som bör identifieras och beskrivas. Nedanstående punkter är organiserade i Organisation (O), System (S), Människa (M) och Data (D). O: Typ av verksamhet som det skall stödja - operativt system, - ledningssystem, - intranät.
O: Organisation - mål och strategi - övriga förändringsåtgärder - ledningsfilosofi - beslutsordningar - geografisk spridning S: En- eller flerfunktionalitet - lönehantering - intranät S: Tillgänglighet - geografiskt - tidsmässigt S: Komplicerat icke komplicerat - tekniskt - processer S: Förändringsbarhet - statiskt dynamiskt - slutet öppet M: Användare - antal - kända/okända - flera kategorier M: Utbildningsbehov M: Gränssnitt - genomskinlighet - individualiseringsmöjligheter - möjlighet till adaption D: Data - mängd - spridning - bearbetningar - transaktioner, antal - struktur/komplexitet - behörigheter - uppdatering, av vilka D: Gränssnitt till andra informationssystem - mängd - hur sker utbytet? D: Aktualitet/Historik
Verktygslådan: Här återfinns designerns erfarenhet, befintliga metoder och fristående metoddelar, beskrivningstekniker, CASE-program, ritprogram och presentationsverktyg. Vidare finns här beskrivningar och stöd till olika praktiska arbetssätt (scenarioteknik, brainstormingbeskrivningar, tumregler för val, idégenerering mm). Denna verktygslåda är input i både modellen för grovdesign samt i metametoden som sedan skall utmynna i en specifik metod där delar av verktygslådan återfinns (används). Verktygslådan skall ses som ett utvecklingsstöd som kontinuerligt uppdateras och utvecklas. Behov av metodikutveckling inom verktygslådan finns. Här kan nämnas aspekter på intranät som är viktiga att på något sätt fånga upp och som det idag inte finns något hjälpmedel för individanpassning av gränssnitt, konstruktion av intelligenta agenter och dylikt. 3 Diskussion och motivation till ovanstående förslag Dagens systemutvecklingssituationer är i högre grad än tidigare mer komplexa och med ibland okända aktörer (jämför webbportaler) samt kräver snabbare utvecklingsresultat i och med att teknikutvecklingen forceras. Morgondagens designer kommer därför att behöva fokusera mera på olika aspekter på verksamhet och informationssystem än vad som de facto görs i dag. Behovet av att till exempel abstrahera och generalisera finns inom flera designdiscipliner. Erik Lerdahl vid NTNU (2000) har under en kreativitetskurs för produktdesigners testat en modell där abstrahering ingår som en del. Studenter som testade modellen i konkreta studentprojekt där produkter skulle designas, konstaterade att de hade svårighet med abstraheringen, men att de insåg vikten av detta för att inte på ett för tidigt stadium fastna i detaljer och se produkten (jämför systemutvecklaren låsning vid uppenbara systemlösningar) för tidigt. De designkriterier och förutsättningar som vi anser bör ligga till grund för metodikutveckling grundar vi på och motiverar med att dagens systemutveckling i hög grad sker traditionellt med användande av äldre metodik där utvecklingsarbetet i allt för hög grad är lösningsorienterat och fokuserat på dagens (läs gårdagens) teknik. Skall vi ställa krav på morgondagens informationssystem, bör vi också ha det modet att designa och specificera dessa utan att lägga in begränsningar i våra beskrivningar. En anledning till det lösningsorienterade synsättet är även att använd metodik i hög grad löste den problematik som gällde gårdagens informationssystem som främst var inriktad på rationalisering och automatisering av verksamhetsprocesser. Vår modell flyttar fokus från nuläget till en mer framtidsinriktad design, och tvingar aktörerna att göra en ordentlig design. Större designinsats läggs på bidrag till verksamheten och sammanhanget där förändringen skall verka. Den totala utvecklingstiden blir troligen densamma som idag och kanske även kortare då underlaget från grovdesignen styr upp fortsatt arbete och möjliggör att detta i hög grad kan ske parallellt och snabbare. Vår modell medför att utvecklaren utifrån den specifika situationen väljer metoder och metodsteg. Han kan inte längre slaviskt följa en i förväg bestämd metodik vilket ibland kan leda till att viktiga metodsteg uteblir eller andra metodsteg överarbetas eller görs i onödan Resultatet av grovdesignen, val av specifik metod (situationsanpassad metod), ligger till grund för vidare planering av det fortsatta arbetet. Detta möjliggör som nämnts tidigare, parallell utveckling och därmed kan även utvecklingsarbetet snabbas upp. Med beteckningen grov avser vi inte slarvig eller hafsig utan att design skall vara top-down och utgå från ett
helhetsperspektiv övergripande strategier etc. Den mer detaljerade designen av enskilda funktioner kommer i ett senare skede Företag och organisationer förändras i högre grad än förut vad gäller inriktning, kundprofil, struktur och så vidare. Morgondagens informationssystem måste designas och konstrueras med hjälp av modeller och metametoder som medger flexibilitet och anpassning till aktuell situation. De designkriterier, principer och förutsättningar som anses vara viktiga skall prägla arbetssättet i hela utvecklingsarbetet. Metoder, miljöer mm skall utformas väljas utifrån detta perspektiv. 4 Slutord Nedan följer några frågeställningar som vi inte täckt in i detta paper, men som det är angeläget att studera vidare: Hur bör lämpliga beskrivningstekniker och arbetsmetoder se ut för att beskriva det karaktäristiska hos ett informationssystem, t ex. ett intranät? För att kunna analysera och fastställa ett företags teknikfilosofi hur medvetandegör och lär vi ut vad teknikfilosofi är samt hur avmystifierar vi IT vilket torde vara behövligt för att få svaret på den förra frågan, samt hur mäter vi förväntningar och användande av teknik som kanske inte ens är implementerad ännu? Frågor rörande gemensamgörande av teknikfilosofi, ny syn på behörighet etc, hotar på sätt och vis existerande maktstrukturer. Hur hanterar en designer detta? Bör det undvikas eller finns det förhandlingsmetoder för att nå till någon slags medellösning? Hur skall den fas/arbetssteg utformas där behörighetsklassificering skall ske? I gårdagens informationssystem så var tesen oftast varje människa skall ha tillgång till den information som han eller hon behöver varken mer eller mindre medan det idag i hög grad gäller att vi eftersträvar engagemang, delaktighet och informationsspridning. Informationssystem har i hög grad utformats med push-principen information trycks på användaren vilket ökar risken för information overload medan pull-principen borde vara den gällande. Hur designar vi system så att användaren kan arrangera och plocka den information han/hon behöver. I vilken utsträckning bör och kan en systemdesigner intervenera vid systemutveckling? Är det lämpligt att spela flera roller designer, konstruktör i ett systemutvecklingsprojekt? Vilka yrkesroller/profiler är önskvärda i framtiden inom systemdesign/-utveckling? Hur borde utbildning av morgondagens systemdesigners utformas? Hur utformas modeller och metoder så att de blir genomskinliga d v s synliggör grundläggande antaganden som desamma vilar på. Skall systemutvecklingsmetodik utformas i form av modeller med exempel på frågeställningar och användaren plocka metodsteg och beskrivningstekniker fritt? Skall vi skippa systemutvecklingsmetoder och införa modeller samt specificera en öppen verktygslåda och metoden blir den dokumentation som blir resultatet av det färdiga projektet? Hur överensstämmer detta med utbildning av systemutvecklare? Kan vi lära oss att frångå metoder innan vi använt dem? Hur stämmer detta med ISO-certifiering och krav på standards där dokumentation av processen är väsentlig? Är certifiering och standardisering ett hot mot kreativitet och kvalitet och i så fall på vilket sätt?
Referenser Beer S. (1994), Beyond Dispute, The Invention of Team Syntegrity, Wiley, New York. Feyerabend. P. (1993). Against Method, 3 rd edition. Verso. NY. ISBN 0-86091-646-4 (pbk). Flood. R. (1995) Solving Problem Solving, Wiley, New York. Hägerfors, Ann (1995). Att samlära i systemdesign. Studentlitteratur. Lerdahl, Erik (1997). Skapende prosesser og deres anvendelser i produktutvikkling. Produktutvikkling & Design, symposium 19-20 nov 1997, NTNU, Trondheim, sid 87-96, ISBN 8291917-01-9 Lerdahl, Erik (2000). A conceptual model for a visionary approach to design. Presented at Proceedings of NordDesign 2000. Aug. 24-25. Dept of Control and Engineering Design. Technical University of Denmark, pp 245-254. Schön, D. (1983). The Reflective Practioner, How Professionals think in Action. Basic Book. NY. Simon, H. (1998). The Science of the Artificial. MIT Press, 3 rd ed. Cambridge, Ma. Stolterman E. (1991), Designarbetets dolda rationalitet, doktorsavhandling, Informatik, Umeå. Universitet. Van Gigch. J. P. (1991). System Design modeling and metamodeling. ISBN 0-306-43740-6. Plenum Press. New York. Warfield. J. N. A (1990). Science of Generic Science Managing Complexity through Systems Design. Intersystems Publ. Vol 1-2. Salinas CA. Warfield, John N. (1994). A Science of Generic Design: Managing Complexity Through Systems Design. Ames, Iowa: Iowa State University Press, 2d, Internetadresser De Bono E. http://www.edwdebono.com/debono/shcd1.htm 2001-01-09