Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Transkript

1 Kurs: Designm etodik, 3 p Delm om ent: Datum : Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se]

2 Innehållsförteckning INLEDNING... 1 MÅL OCH SYFTE... 1 Problemformulering... 1 RESULTAT... 2 UTVECKLINGSMODELLER... 2 Vattenfallsmodellen... 2 Livscykelmodellen... 3 MOCK-UP... 4 DISKUSSION... 6 MOCK-UP... 6 VAL AV UTVECKLINGSMODELL... 6 KOMMUNIKATIONEN I UTVECKLINGEN... 6 LITTERATURFÖRTECKNING... 7

3 Inledning Vid utveckling av datoriserade system är det viktigt att ha med användaren i utvecklingen. Genom att integrera dem och arbeta i en genomtänkt utvecklingsprocess kan företag spara både tid och pengar. Många datoriserade system som utvecklats uppfyller inte användarens krav men har ändå kostar stora mängder pengar. För att utvecklarna ska kunna göra system bättre måste de sätta sig in i användarens behov. För att lyckas med detta måste det finnas bra sätt att kommunicera på. Mål och syfte I denna uppsats är mitt mål att belysa att kommunikationen i utvecklingen är viktig samt om olika utvecklingsmodeller har olika förutsättningar för att nå bra resultat. Problemformulering Har olika utvecklingsmodeller olika förutsättningar för att nå ett lyckat resultat samt kan kommunikationen öka med hjälp av mock-uper? 1

4 Resultat Utvecklingsmodeller För att kunna se hur olika aktiviteter är relaterade till varandra vid skapandet av nya system använder man sig av olika modeller. Alla olika utvecklingsmodeller har för och nackdelar. För att kunna se vilken modell som är mest effektiv måste utvecklaren se till vilket sammanhang den ska användas i. Vattenfallsmodellen Vattenfallsmodellen kallas ofta för traditionell livscykelmodell. Modellen ger en bild av systemets hela livscykel. En ny fas i modellen kan inte påbörjas förrän den gamla är helt färdig. En fas i vattenfallsmodellen som är slutförd kan inte gås tillbaka till och ändra i efterhand 1 De problem som eventuellt uppstår längre fram i tiden skjuts på framtiden, ignoreras eller kodas runt. Dock finns det en viktig återkoppling mellan faserna, men det kan bli kostsamt och problematiskt att åtgärda i efterhand. Fasernas utseendet och namnen på dem varierar mellan olika utvecklingsmodeller men vattenfallsmodellen börjar med kravanalys och kravdefinition. Målet med denna fas innebär att man specificerar vad systemet ska kunna göra och inte göra utifrån användarens mål och önskemål. I fasen ser man även till vilka personer som kommer att vara berörda av systemet och i vilken miljö som den ska användas i. När fasen är färdig går man vidare till nästa fas: system och mjukvarudesign. I denna fas görs en struktur på hela systemet och det utförs en utförlig beskrivning av systemet och dess funktioner. När denna fas är färdig görs implementation och deltestning som innebär att man testar de delar av systemet som är färdiga och försäkrar sig om att de uppfyller kraven som finns i kravspecifikationen. Med Integrering och systemtest menas att systemdelarna sätts in i sin helhet och testas för att vara säker på att systemet uppfyller sina krav i sin helhet. Efter att testningen är färdig levereras systemet till kunden. Den sista fasen är drift och underhåll som är den aktivitet som tar längst tid och kräver mest resurser av alla faser. Systemet installeras och sätts i användning. Eventuella fel som inte upptäckts i tidigare faser rättas till i underhållsdelen. Detta kan vara mycket tidsödande och kostsamt. 2 1 Preece, J, Rogers, Y and Sharp, H, (2002) s 187 f 2 Sommerville, I, (2002) s 44 ff 2

5 Vattenfallsmodellen ska endast användas när användarens krav är helt tydliga och helt förstådda av utvecklarna. När utvecklingsprocessen har gått framåt och kunden blivit en del av systemutvecklingsprocessen har vattenfallsmodellen visat sig vara otillräcklig. Vid många tillfällen kan kundens krav och önskemål lätt misstolkas och/eller vara vagt definierade, detta kan göra att de behöver ändras mitt i processen. Om utvecklingsmodellen inte tillåter att det gås tillbaka en fas och ändras i kravspecifikationen kan det innebära att kunden i slutändan får ett system som man inte kan använda. Förseningar i utvecklingen förekommer ofta då utvecklare måste vänta på andra utvecklare som färdigställer sina deluppgifter. En liten del av iteration är nu inbyggd även i vattenfallsmodellen men fördelen att kunna utvärdera systemet med användaren är ännu inte inbyggd i denna modell. 3 Livscykelmodellen Olika iterativa modeller har utvecklats för att gottgöra vattenfallsmodellens brister. Största skillnaderna ligger i att man försöker få med användaren så mycket som möjligt i utvecklingen. Livscykelmodellen uppfyller kravet med att vara användarecentrerad. Modellen är iterativ med vilket det menas att man kan gå tillbaka mellan olika faser och kontrollera att man jobbar mot användarens krav och önskemål samt möter dem. De uppgifter som finns är i stort sett samma som i vattenfallsmodellen, om kraven som kunden för systemet har skulle ändras finns dock en medvetenhet om att detta ska kunna göras. 4 Vid utveckling med livscykelmodellen kan utvecklaren gå tillbaka mellan faserna och ändra om något skulle visa sig vara fel. Olika faser kan överlappa en annan och ibland kan man behöva gå tillbaka till en fas och komplettera den. I livscykelmodellen visas hela systemet från att det föds till dess att det avvecklas. I livscykelmodellen ingår faserna: Förändringsanalys Analys Utformning Realisering Implementering Förvaltning och drift Avveckling Erling S Andersens livscykelmodell 5 börjar med förändringsanalysen. Andersen anser att denna del inte höra till den traditionella 3 Preece, J, Rogers, Y and Sharp, H, (2001) s 185 ff 4 Sommerville, I, (2001) s 46 5 Andersen, Erling S, (1994) s 41 3

6 systemutvecklingen. Det första som görs är att beskriva nuläget och sätta sig in i den nuvarande verksamheten. Här analyseras de problem och möjligheter som finns och man beskriver den önskade situationen. För att utvecklingen ska bli lyckad är det viktigt att Det är viktigt att användaren är med redan i denna fas av utvecklingen. Tillsammans tittar man på hur det nuvarande läget och den önskade situation ser ut samt förändringsbehovet. Den andra fasen kallas analys och är uppdelad i två delar. I verksamhetsanalysen analyserar man användarens arbetsuppgifter och ser på vilket sätt ett informationssystem kommer att underlätta i verksamheten. I andra delen av analysen som kallas informationssystemanalys ska man bedöma vad som ska finnas med i systemet. Resultatet av denna fas är en kravspecifikation. Den tredje fasen, utformning delas också upp i två delar. Den första kallas Principiell utformning av teknisk lösning och här väljs den tekniska lösningen som önskas. Det är viktigt att se den lösningen som är mest ändamålsenlig för verksamheten. Även om man är van och känner sig säker på sitt gamla system så får man inte vara rädd att testa något nytt. I andra delen, Utformning av utrustningsanpassad teknisk lösning, väljer man vilken utrustning man ska använda sig av till exempel vilket operativsystem, hur data ska lagras och vilket programspråk som ska användas. Fjärde fasen är Realiseringen där själva informationssystemet utarbetas och programmeras. Implementeringen är sista fasen som ingår i systemutvecklingen. Systemet implementeras i verksamheten. I fasen Förvaltning och drift ska systemet underhållas och förbättringar ska göras. Sista fasen kallas Avveckling. Här är det viktigt att säkra den information som finns lagrad i systemet, när systemet ska läggas ner. För att kunna jobba på detta sätt krävs en aktiv kund som är villig att lägga ner tid och resurser på att testa och godkänna eller förkasta förslagen som utvecklarna kommer fram till. Andersen beskriver utvecklingsarbetet så här: Användarnas uppgift är att fastställa vad man önskar uppnå. Experternas uppgift är att finna de tekniska lösningar som ger användarna vad de önskar. 6 Mock-up Att omsätta en vision i en operativ bild innebär att åskådliggöra, precisera och detaljera. För att gestalta denna bild krävs det någon teknik för att själv kunna tolka den och att kunna kommunicera den till andra. En operativ bild innehåller tankar om dellösningar och delfunktioner. Genom att bygga upp denna bild kan konflikter och motsägelser som inte syns i en mer 6 Andersen, Erling S, (1994) s 39 ff 4

7 övergripande vision förebyggas. Genom olika sätt kan en operativ bild gestaltas, bland annat genom en så kallad mock-up. En mock-up är en dynamisk pappersprototyp som syftar till att illustrera det blivande systemets interaktivitet. Denna teknik är speciellt användbar då kraven från användaren är svåra att specificera direkt. Med en testmodell visar man systemet ur olika perspektiv för att åskådliggöra den tänkta byggnaden. En mock-up ses som en förenklad version av systemet. Dess idén bygger på att man förbereder ett antal dialogtillstånd av bilder som användaren kan hamna i. Under testningen och demonstration av prototypen agerar man själv fönsterhanterare. Genom att demonstratören låtsas klicka på olika knappar eller skriva något i ett fält visas olika sidor beroende på vilken inmatning som gavs. Fördelarna med en mock-up är att den kan ge en bra känsla för systemets interaktiva beteende men även att de är enkla och billiga att bygga samt lätta att använda. En nackdel kan vara att det är svårt att gestalta vissa saker till exempel då man har för avsikt att använda sig av direkt manipulation. 7 Direkt manipulation är när man märker det användaren utför direkt som output, exempelvis ändrar volymen. 8 Mock-uper är ett stort stöd i utvecklingen och i kommunikationen. Man låter kunden och utvecklaren vara jämspelta. Denna typ av tillvägagångssätt kräver en engagerad kund som är beredd att lägga ner tid för att sätta sig in i, testa och godkänna mockupen. Det är viktigt att hitta ett gemensamt språk mellan slutanvändare och utvecklare, annars är det lätt att missuppfatta varandra. Trots att teamet och slutanvändaren använder samma termer kan de ha olika betydelse för de båda. Detta sätt att arbeta på, underlättar då en kravspecifikation ska skrivas. Genom arbetet kan användare och utvecklare se att man är på samma nivå och förstår varandra. Alla människor har olika bakgrund som ger olika erfarenheter och perspektiv. Vid utveckling i team är det svårt att tillgodose allas viljor men tankarna kan även ses som en fördel, då flera infallsvinklar på problem kan belysas. När utveckling sker i team är det viktigt att projektledaren plockar ut bra och dåliga idéer för slutanvändarens behov. Den grafiska designen på en programvara utvecklad för vana datoranvändare kan enkelt förstås för dessa, men ge komplikationer för en användare som aldrig förut arbetat med en dator. 7 Löwgren, J, Stolterman, E, (1998) s Preece, J, (1994) s 270 f 5

8 Diskussion Mock-up I alla projekt tror jag att den slutlige användare och utvecklare får problem med att förstå varandra. Om mock-uper används vid utveckling tror jag att en aktiv användare i utvecklingen av ett system och utvecklaren kan öka förståelsen mellan varandra och skapa en bra slutprodukt och ett bra resultat. Mock-uper kan göras på det viset som Lövergren och Stolterman skriver men jag tror även att andra metoder kan användas, exempelvis program i datormiljö. Dock tror jag att det då krävs att användaren är insatt i hur ett sådant program fungerar för att kunna se möjligheter och förstå hur han själv kan vara med att påverka utan att känna sig underlägsen. Det är viktigt att få fram kreativa idéer och de kan kanske eventuellt hämmas om inte användaren förstår fullt ut vad som visas och hur han kan påverka. När utvecklingen nått fram till en punkt då grundstommen och koncept för hur det nya programmet ska se ut finns och hur det ska användas tror jag att det kan vara bättre att försöka visualisera det genom skärmbildsprototyper istället för pappersprototyper. Användaren ser eventuellt en pappersprototyp som något tillfälligt och kan acceptera vissa fel som givetvis kan finnas på papperslappar men vid en skärmbildsprototyp kanske felet ses mer tydligt och mer oacceptabelt. Jag tror dock att det är viktigt att inte stressa fram denna process utan låta användaren och utvecklaren genom hela utvecklingen förstå varandra. Val av utvecklingsmodell Jag tror att olika utvecklingsmodeller har olika förutsättningar. Företag som vill belysa vissa delar har även möjlighet att skapa och forma en egen modell att utveckla om så önskas. Dock tror jag att det är viktigt att använda sig fullt ut av en iterativ modell. I de fall som inte det görs finns risker att produkt och resultat inte alls motsvarar det som användaren önskar av systemet som utvecklas. Genom den iterativa modellen finns det alltid möjlighet att korrigera fel som gjorts, dock kanske man få väga det mot kostnader för att göra det. Kommunikationen i utvecklingen Jag tror att kommunikationen mellan användare och utvecklare kan ökas genom att använda sig av mock-uper. Dock måste båda parter engagera sig i utvecklingen för att det ska lyckas. Genom enkla medel kan utvecklingen ske på ett lättbegripligt sätt, även för den som vanligtvis inte arbetar med programutveckling. Det är viktigt att låta användaren för det framtida systemet vara en del av utvecklingen och ta in reflektioner från denne för att lyckas på ett bra sätt. 6

9 Litteraturförteckning Andersen, Erling S. (1994) Systemutveckling principer, metoder och tekniker, Studentlitteratur, Lund. Löwgren, Jonas, Stolterman, Erik. (1998) Design av informationsteknik materialet utan egenskaper, Studentlitteratur, Lund. Preece, Jenny. (1994) Human-Computer Interaction, Addison-Wesley Publishing company, New York. Preece, Jenny, Roger, Yvonne, Sharp, Helen. (2002) Interaction Design, John Wiley & Sons Inc,Crawfordsville. Sommerville, I. (2001) Software engineering, Pearson Education Ltd, Harlow. 7