Rapport för Projekt Alhanko

Transkript

1 Rapport för Projekt Alhanko på uppdrag av Kungliga Operan i KTH-kursen 2D1954 Programutvecklingsprojekt,

2 Sammanfattning...3 Projektmedlemmar...3 Uppdragsgivare...3 Kontaktperson... 3 Projektwebb...3 Projektuppgift...4 Bakgrund... 4 Problembeskrivning... 4 Syfte... 4 Krav... 4 Avgränsningar:... 4 Utvecklingsarbete...5 Ansvarsfördelning... 5 Arbetsmetod... 5 Gränssnittet... 5 Utveckling av gränssnittet... 5 Testning av gränssnittet...6 Definitioner... 6 Problemformulering / testsyfte... 6 Metoder / testdesign... 6 Utformningen av gränssnittet... 6 Test av funktionaliteten... 7 Användarprofil... 7 Testpersonerna... 7 Uppgifter i testen... 7 Testledarens roll... 8 Förväntade data... 8 Tidsaspekter... 8 Funktionalitet... 8 Tack till... 8 Resultat...9 Bilaga 1 Etikettutskrifter

3 Sammanfattning Denna rapport avser ett projektarbete i kursen 2D1954 Programutvecklingsprojekt vid KTH, Kungliga Tekniska Högskolan i Stockholm, våren Arbetet på Kungliga Operan (nedan kallat KO) kräver stor dokumentation över vilka inventarier, dekorer och rekvisita som tillhör vilken föreställning och vart de finns lagrade i Operans lokaler. Idag finns flera dokumentationssystem, allt från enkla papper-och-penna-skisser till avancerade CAD-ritningar i datormiljö. Vi fick till uppgift att sammanföra några av systemen till ett system med en gemensam databas där användarna kan föra samma typ av dokumentation som idag och göra sökningar och listor med datorns hjälp istället. Projektet fick namnet Alhanko (nedan kallat PA) efter prima ballerina Anneli Alhanko. Projektmedlemmar Elin Francke Joanna Kühn Daniel Myrbäck Lennart Hedlund Clara Edman Robert Trouin ef@kth.se joannak@kth.se myrback@kth.se hedlund@kth.se clarae@kth.se rtr@kth.se Projektets e-post: pr02-alhanko@nada.kth.se Uppdragsgivare Kungliga Operan AB Box Stockholm Kontaktperson Kurt Blomquist, scenchef Telefon: E-post: kurt.blomquist@operan.se Projektwebb 3

4 Projektuppgift Bakgrund KO är en repertoarteater med många olika produktioner där varje produktion innehåller mycket rekvisita och dekor. För att organisationen ska flyta smidigt gäller det att ha god översikt över alla delar. Idag har man flera olika dokumentationssystem för att åstadkomma detta. Problembeskrivning Projektgruppens, PA, uppgift är att designa och implementera en databas över KO:s rekvisita, dekorer och inventarier, här generellt kallade objekt. Databasen skall bland annat kunna ge en översikt över de objekt KO innehar, stödja bokning av objekten till föreställningar samt att visa vilka objekt som ingår i en föreställning, s.k. innehållsförteckning, alternativt vilka föreställningar som bokat ett visst objekt. Ett grafiskt lättanvänt användargränssnitt ska utvecklas som stöder ovan nämnda funktioner. Syfte Systemet ska fungera som ett enkelt verktyg och kunna ge en översikt över tillgängliga resurser vid arbetet på KO. Krav Databasen skall köras på en Linuxserver. Systemet skall kunna köras i befintligt datornätverk. Varje ansvarsområde ska ll snabbt få tillgång till, för dem, väsentlig information. Exempelvis olika typer av innehållsförteckningar och utskriftsformulär. Hantera utlåning/uthyrning av objekt Hantera inventarier (objekt med avseende på värde över ett visst belopp) Användarvänligt gränssnitt Avgränsningar: Då tiden är projektets största hot kommer PA: s primära mål att vara att designa och implementera databasen samt skapa gränssnitt och funktionalitet för att lägga in och boka upp objekt i databasen. Man skall även kunna ställa frågor såsom sökningar och listningar. Det ligger inte inom projektets ramar att propagera databasen ( fylla på databasen med verkligt data ), endast några få objekt kommer att skapas för att säkerställa funktionaliteten. 4

5 Utvecklingsarbete Ansvarsfördelning Under förstudien gjorde vi en enkel kartläggning över vad alla hade för förkunskaper och gjorde en grov rollfördelning. Under arbetets gång har det emellertid utkristalliserats till mer formella roller. I förstudien deltog alla vid val av design och hur arbetet skulle gå till. roll: men har dessutom medverkat i: Elin projektledare gränssnitt, implementation Joanna testledare dokumentation Daniel systemarkitekt implementation Lennart kundkontakt databas, gränssnitt Clara gränssnitt gränssnitt, dokumentation Robert dokumentation databas, dokumentation Arbetsmetod Projektarbeten som detta kan styras med hjälp av ett flertal etablerade metoder. Vårt uppdrag åt Operan var tämligen fastställt, en åtskillig mängd data över rekvisita och inventarier skulle lagras i en databas. Arbetet delades upp i gruppen för att samla de olika kompetenserna. För att få ett så överskådligt system som möjligt har vi gjort en så enkel design som möjligt utan att rucka på kraven. Denna arbetsmetodik brukar kallas extreme programming. Gränssnittet För att kunna utforma och sedan utvärdera gränssnittet skapades en testplan som stöd och planering i arbetet. Den största utmaningen var att identifiera facktermer och annan Opera-specifik information för att få ett gränssnitt som i största möjliga mån talar användarnas språk. För att utvecklaren skulle få större insikt och kännedom om Operans verksamhet gjordes två besök, ett observationstillfälle hos dekoravdelningen och ett deltagande observationstillfälle 1 hos rekvisita. Utveckling av gränssnittet I ett första steg togs pappersprototyper fram för att få en generell överblick av vilka sidor som skulle behövas i gränssnittet. Tanken var att dessa sidor också skulle utgöra det första användartestet hos kunden men det blev istället så att den första presentationen skedde på whiteboardtavlor med utgångspunkt från pappersprototyperna och det var snarare ett möte av kooperativ design än ett vanligt användartest. I andra skedet skapades en mycket enkel prototyp av gränssnittet på dator vars länkar ledde till logiska händelser. På denna prototyp utfördes två expertutvärderingar och två användartester. Expertutvärderingarna gjordes av teknologer utbildade i människa-datorinteraktion efter tio heuristiker 2 och användartesterna skedde på Operan. Efter dessa resultat utvecklades då det slutgiltiga gränssnittet samt implementerades av en av gruppmedlemmarna. 1 Observation under deltagande, man följer med den man observerar; som en lärling. 2 Se separat dokument med heuristiker 5

6 Testning av gränssnittet Definitioner Med produkten menas hela databassystemet, där användargränssnittet är den del av produkten som användarna interagerar med. Med användare menas dels de verkliga slutanvändarna, eftersom tanken är att databasen ska användas på riktigt, men även de användare som endast ingår i syfte att testa och utvärdera produkten. Att användarna har datorkunskaper innebär att de har hanterat Microsofts Windows med Officepaketet, men de har inte programmerat eller gjort mer avancerade saker. Att surfa på Internet ingår. Med gränssnitt menas användargränssnitt, där inget annat anges. Problemformulering / testsyfte Det huvudsakliga syftet med testerna är att kontrollera att databasen och dess gränssnitt innehåller alla de funktioner och de objektegenskaper som är vitala för att systemet ska kunna användas. De frågor som testet förhoppningsvis ger svaret på är: Klarar slutanvändarna av de uppgifter som de ska kunna klara av att lösa i testen? Det vill säga, hjälper produkten användarna, eller är den bara en belastning i det dagliga arbetet på Operan. Innehåller produkten några grundläggande felaktigheter som gör att det är svårt att slutföra givna uppgifter? Tar det lång tid att lista ut hur man ska göra något, eller att hitta viss information. Olika tid krävs för olika uppgifter. Är det en lagom blandning av lättanvändbarhet kontra lättlärdhet? Upplevs systemet som komplicerat och svårt att sätta sig in i? Måste man lära om efter en tids frånvaro eller är det intuitivt, det vill säga, går det att lista ut vad som ska göras om användaren har basala datorkunskaper. Stämmer slutprodukten väl överens med slutanvändarnas konceptuella modell av systemet? Känner slutanvändarna att det som de var med och utvecklade, verkligen var det de fick i slutändan, med vissa modifikationer. Metoder / testdesign Det kommer att vara flera olika typer av tester under projektets gång. Detta för att det är ett stort projekt med ett ganska komplicerat användargränssnitt. De tester som kommer att utföras är dels ett där själva gränssnittet utformas, dels ett där det kommer att vara hela databasgränssnittets funktionalitet och användbarhet som testas. Det vill säga, kontrollera om systemet uppfyller de krav som specificerades i början av projektet. Utformningen av gränssnittet Enligt projektspecifikationen utformas gränssnittet i samarbete med användarna och efter ett skelett som projektgruppen lägger fram. Detta för att de tekniska begränsningarna ska tas med redan i planeringsstadiet, som en tidsbesparande åtgärd. 6

7 Den del av projektgruppen som är ansvarig för gränssnittet utformar det sedan med hjälp av heuristiker 3 och genom att gå igenom användningsfall. En expertutvärdering kommer att utföras av en, i gruppen icke delaktig, person med erfarenhet av databasimplementation och gränssnitt. Testerna görs på ett primitivt utformat gränssnitt som endast innehåller funktionalitet, utan att på något vis blivit designat. Orsaken till att redan de första testerna görs på ett implementerat gränssnitt är att de tekniska begränsningarna är ganska omfattande och därför finns det inte så stort utrymme för förändringar. Test av funktionaliteten Testet av funktionaliteten kommer att ske framför en dator, antagligen i ett använbarhetslabb, med två rum sammanlänkade av en envägsspegel. Testle - daren kommer dock att sitta med testpersonen under testet och svara på frågor. Observatörer, i detta fall utvecklarna och de som implementerat systemet, kommer att sitta i det andra rummet och iaktta och anteckna. Testet kommer även att spelas in på video för vidare analys, eventuellt i samarbete med testpersonen. Detta är en djupare analys av vad som verkligen hände. En del slutanvändare kommer att vara testpersoner och i samband med detta test kommer den sista frågan om produkten att besvaras; Stämmer slutprodukten väl överens med slutanvändarnas konceptuella modell av systemet? Detta åstadkoms genom att ha en längre intervju med slutanvändarna. Användarprofil Det kommer att vara tre användarkategorier; administratören, de som arbetar på dekor sidan och de som arbetar på rekvisita sidan. Testpersonerna Som testpersoner kommer slutanvändarna att användas, i alla fall till sluttestet. För expertutvärderingen kommer en extern person med kunskap om gränssnittsutveckling och databasdesign att användas. Den heuristiska utvärderingen av användargränssnittet, samt genomgången efter användarfall, kommer att göras av utvecklarna själva. Uppgifter i testen I den första testomgången kommer testpersonerna att få prova att söka efter föremål och lägga till föremål. De är de funktioner som alla övriga funktioner beror av, eftersom det för att boka ett föremål krävs att man kan söka efter ett föremål. Samma sak gäller för att kunna ta bort föremål. De föremål som de ska lägga till (detta är den viktigaste delen av testet eftersom det är viktigt att alla objektegenskaper som behövs verkligen har kommit med) får de själva välja, men testledaren uppmuntrar dem att ta de objekt som dels är typiska föremål för avdelningen, dels sådana som läggs in ofta, samt sådana som är mer komplexa. I det andra testfallet kommer testledaren ha utforma scenarios som ska efterföljas. I båda testfallen, utformning och funktionalitet, kommer testen att vara uppgiftsorienterade, dvs. testpersonerna kommer att få vissa uppgifter som ska lösas i samarbete med testledaren. Vilka dessa uppgifter ska vara kommer att kopplas till slutanvändarnas behov från systemet. 3 ( 7

8 Dessa uppgiftslydelser kommer att presenteras skriftligt, och kommer endast att vara åtkomliga vid testets start. Testpersonerna kommer alltså inte att få reda på sina uppgifter i god tid innan. Testledarens roll Testledaren kommer att vara en av utvecklarna, i alla fall för pilottestet och den första testomgången. Detta därför att testledaren har haft mycket kontakt med testpersonerna. Förväntade data Tidsaspekter Eftersom den mesta av inmatningen sker för hand, har det inte tagits hänsyn till hur lång tid olika operationer tar. Detta eftersom tiden för manuell inmatning skiljer sig markant mellan olika användare. Funktionalitet Det är viktigt att slutanvändarna kan använda systemet utan alltför hög inlärningströskel, därför kommer testerna att särskilt fokusera på det. Det är även viktigt att användarna inte kan påverka systemet negativt, till exempel orsaka att det kraschar, lägga till felaktiga saker och dylikt. Antalet fel kan vara relevant här, det vill säga kvantitativa data, men samtidigt är man intresserad av att få reda på vilka felen är, en kvalitativ analys. Tack till Som avslutning vill vi tacka Anna Stockhaus för hennes förslag och hjälp med att utforma och genomföra testerna. 8

9 Resultat Slutprodukten av detta projekt är alltså en databas som implementerats för MySQL och ett grafiskt användargränssnitt som utvecklats i Java och JSP. Det är en webbaserad systemlösning där man utnyttjar befintliga datorresurser på Operan. Hur systemet tas i drift beskrivs i systemdokumentationen där övrig teknisk beskrivning återfinns. Systembeskrivning och användarhandledning finns i separata dokument. Tillvägagångssätt för hur man löser frågan med etikett-utskrifter från en standardskrivare finns beskrivet i bilaga 3 i enlighet med specifikationen. 9

10 Bilaga 1 Etikettutskrifter PA och KO gjorde en begränsning för utskrifter av etiketter under mötet på Operan den 25 april Då KO inte tyckte att webbläsaren kunde uppfylla deras krav på hur etiketten skulle se ut redogjorde PA för KO att det var en alldeles för stor uppgift att lösa problemet på annat sätt. KO använder sig idag av dedikerade etikettskrivare för att skapa etiketter till främst dekorer. Istället vill man använda standardskrivare för att lösa uppgiften. Då ingen av projektmedlemmarna anser sig kunna tillräckligt om hur skrivare fungerar och hur de kommunicerar med ett datorprogram kom vi överens med KO att vi skulle försöka skriva ner hur det skulle kunna lösas och kopplas till det nya databassystemet. Detta är kort beskrivning på hur man skulle kunna göra. Till att börja med måste man bestämma sig för vilken typ av standardskrivare man skall använda och ta reda på vilket interface den har, kontrollera vilket språk den talar. Det bör vara en postscript-skrivare då det är ett bra sätt att få utskrifterna att se ut som man vill. Sidbeskrivningspråket Postscript specificerar exakt hur ett dokument ska se ut med rit-liknande kommandon, ex.vis "Flytta pennan till koordinat 23/321, använd pennbredd 2, svart färg och rita där en halvcirkel med radien 2 cm med bokstaven R i mitten. På detta sätt kan man beskriva KO:s etikett exakt och få den utskriven på skrivaren. Uppgiften blir alltså att skapa denna postscript-fil i Java-programmet och skicka filen till skrivaren. I samband med att denna fil skapas måste man också läsa avsedd data ur databasen och baka in det i filen. Ett mycket enklare sätt att lösa problemet skulle vara att man använde sig av skurna A4-etikettark i en standardskrivare och låter bygga upp en html-sida som visas direkt i webbläsaren med rutor, rader och symboler där man använder webbläsarens inbyggda utskriftsfunktion. Nackdelen är att man inte får den att se ut som den nu existerande etiketten, men det fyller säkerligen samma funktion i alla fall. Fördelen däremot är att man kan köpa etiketter i en vanlig pappershandel till en lägre pris än dagen etikett. Detta kan åstadkommas på precis samma sätt som resten av systemet är uppbyggt, Java och servlets, som kan läsas om i systemdokumentationen. 10