Läseseminarium 1

Finns det någon annan utvecklingsmetod som inte nämns i boken som kan vara ännu bättre än den iterativa metod som Peter har fastnat för?

En av de andra metoder som gruppen känner till är vattenfallsmetoden, som i princip kan beskrivas till den iterativa utveckling som Peter beskriver. Fördelar med den metoden är att den kan vara enklare och billigare att implementera, men vi E4 anser att den skapar ett beroende där fel troligen inte upptäcks innan slutet av utvecklingsprocessen. Vi förespråkar därför iterativ utveckling, vilken metod även talas varmt om i kursen ”Introduktion till datalogi”.

Finns det projekt där prototyper hindrar arbetsflödet, och hur kan man lösa detta?

Grupp E4 tror att det kan finnas sådana projekt eftersom prototyper kan ta lång tid att utveckla, och om projektet är väldigt tidsberoende, så kan detta ledat till problem under utvecklingen. Ett sätt att lösa det kan vara att använda ”rapid prototyping”. Med hjälp av den metoden kan kostnader hållas ner samtidigt som enkla prototyper kan hjälpa till att illustrera olika aspekter av ett iterativt arbetsflöde.

När ska man sätta en gräns för planeringen? Hur mycket tid ska man lägga på planering?

Vi kan inte enas om en specifik tid som krävs, men om det är en väldigt simpel och specifik uppgift som skall utföras, så bör det inte ta alltför lång tid. Om komplexiteten ökar, så bör även planeringsfasen ges mer tid eftersom det kan eliminera fel i slutändan. Ibland kan man dock vara tvungen att gå vidare för att inte fastna i ett stadium där man ständigt ser nya, alternativa, lösningar som hindrar utvecklingen.

Hur ser kommunikationen mellan designers och utvecklare ut? Hur mycket är utvecklare med i designproccessen?

Förhoppningsvis arbetar de väldigt nära varandra, även om de håller på med helt olika saker som slutligen ska länkas samman för att forma en produkt. Eftersom utvecklare och designers har olika utbildningsbakgrund, går det inte att prata rent designspråk kring vad som önskas. Likaså kan inte en programmerare tala sitt språk för att beskriva vad som faktiskt är möjligt. Således behöver ett standardiserat system användas för att underlätta kommunikation mellan parterna utan att viktig information försvinner i processen att förmedla tankar och idéer. Vi ser att kommunikation är en viktig del i arbetet, och att utvecklare skall vara ytterst delaktiga i designprocessen.

Hur formulerar man tydliga frågor för att kunna leda en intervju?

Vi ser det som en fördel om man väljer att ha många mindre frågor som är mer specifika, än breda frågor som inte alltid garanterar ett användbart svar. Man bör alltid ställa sig frågan: ”kommer vi att få ut något av frågan?”. Trots att det är lätt att svara på ja/nej-frågor, så är det ofta bra att ge folk möjligheten att utveckla sig själva. Detta ger högre förståelse för hur den intervjuade personen tänker, samtidigt som det får den intervjuade att känna sig mer involverad i projektet.

Praktisk tillämpning av teori

Liksom vi har beskrivit tidigare, så tänker vi använda iterativ utveckling i form av att använda många enklare prototyper för att förmedla vårt budskap. Vi tänker även lägga tid på att formulera bra frågor som verkligen hjälper oss att hitta ett område i anslutning till tillämpningar i ett museum som måste utvecklas. Om vi hade oändligt med resurser och tid, skulle vi använda detta till att lägga mer tid på teoridelen av vårt arbete, och sedan driva utvecklingen vidare till det stadium att vi åtminstone har en fungerande prototyp eller efter att ha skapat en färdig produkt.