Specifikation för Projekt Alhanko

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

PROBLEMBESKRIVNING...3 BAKGRUND...3 SYFTE...3 KRAV...3 AVGRÄNSNINGAR:...3 FÖRSLAG TILL LÖSNING...4 SYSTEMSKISS...4 MODULER...4 FUNKTIONER...4 Utskrifter...5 ANVÄNDARGRÄNSSNITTET...5 DATORMILJÖ...5 Hårdvara...5 Mjukvara...6 ANVÄNDARE...6 ANVÄNDNINGSFALL...6 ANVÄNDARVÄNLIGHET...7 TIDSPLANERING AV AKTIVITETER...8 ADMINISTRATION...8 DOKUMENTATION...8 RISKANALYS....9 APPENDIX A...10 APPENDIX B...10 APPENDIX C...10 BILAGA 1...11 2

Projektnamn: Alhanko (PA) Uppdragsgivare: Kurt Blomquist, Kungliga Operan AB (KO) Projektmedlemmar: Elin Francke, projektledare Joanna Kühn, testledare Daniel Myrbäck, systemarkitekt Lennart Hedlund, CRM Clara Edman, gränssnitt Robert Trouin, dokumentation Problembeskrivning Projektgruppen PA:s 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. Bakgrund KO är en repertoarteater med många olika produktioner där varje produktion innehåller många objekt (se ovan). 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. 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 skall snabbt få tillgång till, för dem, väsentlig information. ex 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 3

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. Förslag till lösning Systemet är en så kallad klient/server applikation. Med det menas att databasen installeras och körs i en databasserver medan applikationen som användaren kör på sin dator (klientstation) kommunicerar direkt med databasen eller via ett mellanlager. I vårt fall använder vi det senare och i mellanlagret ligger de funktioner som kräver access till databasen. På det sättet isoleras databasen från direkt interaktion med användaren. Systemskiss Se Bilaga 1 Moduler Databasserver Databasservern innehåller databasen som lagrar alla data i systemet i tabeller. Databasen bör ligga på en separat dator. Databasen kommer av säkerhetsskäl endast vara nåbar via applikationsservern. Det gör att en användare endast kan se det data som applikationen tillåter användaren att se. Vi kommer använda databasen MySQL som är den världsledande gratisdatabasen. Webbserver Webbserver är den eller de datorer som har ett program som sköter kommunikationen mellan applikationen och användarnas klienter, vanligtvis via http-protokollet, alltså det som används för vanliga hemsidor. Vi kommer att använda Apache som webbserver, vilket troligtvis är den mest använda gratiswebbservern för Internetapplikationer. Applikationsserver Applikationsservern kör själva applikationen (programmet) och svarar på förfrågningar från webbservern. Applikationsservern kan ligga på en separat dator eller på samma dator som webbservern. I vårt fall är dessa nära integrerade och ligger på samma dator. Gränssnittet mellan webbservern och applikationsservern är inte intressant ur vår synvinkel. Vi kommer att använda oss av applikationsservern Tomcat som hanterar program skrivna i programspråket JAVA. Klientprogramvara Klientprogramvara är det program användaren använder för att kommunicera med en applikation som ligger på ett annat ställe i ett lokalt eller globalt nätverk (Internet). I vårt fall kommer klientprogramvaran motsvaras av webbläsaren Internet Explorer som finns på alla PC-datorer som har en installation av Windows 95 eller senare version. Funktioner Primärt skall systemet kunna: 4

Lagra information om KO: s materiel i databasen. Objektens olika egenskaper finns i appendix A. Objekten delas in i kategorie r. Vissa objekt är s.k. standardobjekt som kan användas av flera föreställningar parallellt, exempelvis stegar, dansmattor etc. (se egenskapen standardmateriel för objekt) Visa bild på objekten (kräver bildformat som stöds av en webbläsare). Skapa en lista över objekt som ingår i en föreställning/grupp. Egenskaper som ett bokat objekt har finns i appendix B. Dessa objekt skall även bokas upp så att de inte går att bokas till andra föreställningar under samma period. En boknings olika egenskaper finns i appendix C. Hantera utlåning/uthyrning av objekt. Objekt skall kunna reserveras inför planerat underhåll (i princip en vanlig bokning). Utskrifter Utskrifter skall enkelt kunna göras i form av olika listor och förteckningar genom att använda webbläsarens inbyggda utskriftsfunktion. När det gäller utskrifter av etiketter skall PA i ett särskilt dokument kort redogöra för hur systemet skall vidareutvecklas för att stödja sådana utskrifter. Användargränssnittet Gränssnittet ska vara åtkomligt över webben, eftersom det ska kunna användas utanför KO och Sveriges gränser. Eventuellt skulle man kunna tänka sig flera olika användarnivåer, så att en viss användare bara får tillgång till viss information, då främst av säkerhetsskäl. Hur gränssnittet ska utformas rent grafiskt är ännu oklart. Det ska dock vara enkelt att använda. Gränssnittets utformning, layouter och funktioner skall i detalj beslutas tillsammans med KO och innan systembyggnadsstart skall dessa skriftligt dokumenteras (i särskild bilaga) och godkännas av KO. Datormiljö Hårdvara Nedanstående beskriver kraven på implementationshårdvara. För klienterna råder kravet att den skall kunna visualisera dokument som följer HTML 3.0 eller senare dokumentspecifikation. Detta leder fram till det minimala kravet att klient-hårdvaran skall uppfylla de krav som ställs av respektive HTML-installation, oavsett operativsystem. Servern skall vara en så kallad stand-alone server med operativsystemet Linux version <> 7, Apache webbserver med Tomcat applikationsserver, version 3.3 eller senare. Systemet ställer låga krav på processorkraft men en snabb processor är att föredra. Däremot bör den interna minneskapaciteten vara väl tilltagen. Det ger följande rekommendation på server: -Pentium III 800 MHz eller bättre. -256 MB RAM eller mer. 5

Mjukvara Nedan beskrivs endast målsystemets krav. Utvecklingssystemet löses av gruppen själv i samråd med KTH. Klientprogramvara Denna har som enda krav att kunna visualisera HTML-dokument 3.0 eller senare. Detta ger att systemet är operativsystemoberoende men däremot beroende på huruvida HTML-läsaren kan visualisera HTML 3.0 eller senare, dock rekommenderas MS Internet Explorer 5.0 eller senare. Serverprogramvara Operativsystem Linux ver. <> 7 Webbserver Apache med applikationsserver Tomcat ver 3.3, eller senare och kompatibel med. MySQL-databas ver. 3.23.44 eller senare och kompatibel med. Användare Vilka som är de presumtiva användarna är viktigt att kartlägga eftersom det är av central betydelse för utvecklingen av användargränssnittet. Det finns tre skiljda användargrupper i detta system. Systemadministratör har kunskap om både hård- och mjukvaran i systemet, speciellt Apache och Tomcat på serversidan. Leif Age är KO:s systemoperatör. Privilegierad användare har goda kunskaper om KO:s verksamhet och rättigheter att både lägga in och läsa information i systemet. För närvarande är följande personer privilegierade användare: Kurt Blomquist, Nils Bylon, Anders Nopp, Lars Inge Sernklev m fl, Leif Eriksson, Per Lundström, Lars Göran Abrahamsson, Per Almqvist, Jan Holmgren, Rune Dahlman, Erik Dahlberg, Produktionsassistenter (aktuell produktion) Användare har rättigheter att enbart läsa information från systemet. Med läsa information avses att kunna mata in nödvändig information i avsedda fält för att starta en sökning och få ut resultatet på skärm eller skrivare. Användningsfall Logga in Användare loggar in på systemet och får genom sin identitet tillgång till behöriga resurser. Om access nekas meddelas detta. Administrera användare Systemadministratören kan här ge de olika existerande användarna rättigheter till systemet. De rättigheter som är definierade idag är visa, förändra. Med visa avses läsa men ej kunna förändra. Med förändra avses att kunna visa och kunna ändra, ta bort samt lägga till objekt eller grupperingar därav. Användarna och dess rättigheter lagras i databasen. Skapa och modifiera objekt Privilegierad användare kan lägga till, ta bort, förändra och flytta olika objekt och dessa attribut. Objekten lagras i databasen. 6

Skapa och modifiera föreställning Privilegierad användare kan lägga till och förändra olika föreställningsobjekt. Med förändra avses också att kunna lägga till/ta bort objekt kopplade till föreställningen. Föreställningsobjekten lagras i databasen. Boka objekt eller föreställning Privilegierad användare kan boka/avboka enskilda objekt och hela föreställningar för olika tidsperioder. Med tidsperiod avses enstaka tillfällen liksom repetitiva tillfällen. Bokning sker med upplösning om dag. Bokning skall i repetitiva tillfällen kunna ske över en viss tidsperiod eller med repetitiva ele - ment så som t.ex. varje måndag och onsdag i tre månader framåt. Bokningarna lagras i databasen. Skapa/visa listor Användaren kan inspektera enskilda objekt, hela grupperingar av objekt eller en föreställnings objekt. Om bild (ritning och/eller foto) finnes tillgänglig så visualiseras de/denna. Kommentar: Att ta bort ett objekt måste bekräftas med att svara Ja på efterföljande fråga. Med att ta bort ett objekt menas inte att det raderas för alltid, bara att objektet markeras som inaktivt. Det gör det enkelt att aktivera det igen vid ett senare tillfälle. Användarvänlighet Tangentbordsorienterad, logisk tab-ordning Visa all text i textfält med s.k. tooltip, dvs. en "gul ruta" när man håller muspekaren över textfältet. 7

Tidsplanering av aktiviteter Vecka 9 Vecka 11-12 Vecka 13-15 Vecka 16 Vecka 17-18 Slutlig specifikation och avtalsskrivning. Design av databas och gränssnitt. Implementering av databas, JSP -sidor m.m. Testning. System med dokumentation färdigställs. Administration Interna möten hålls minst en gång per vecka, lämpligen på måndagar då kursen är schemalagd. Kontinuerlig kontakt skall hållas med KO, dock mest efter behov. Minst två inbokade möten med beställaren kommer att ske dels för att rapportera projektets status och dels för överlämnande av systemet. Dokumentation Dokumentation sker fortlöpande under projektets gång av alla projektmedlemmar. Följande dokument skall tas fram inom ramarna för projektet: Källkod kommenteras och dokumenteras av respektive utvecklare under utvecklingens gång. Javadoc, som är en standardiserad dokumentation av källkod skriven i Java, genereras från källkoden. Systembeskrivning beskriver arkitektur och flöden och vilka komponenter som ingår i systemet. Användarmanual tas fram i projektets slutskede med utgångspunkt från användarna. 8

Riskanalys. Risk Det kan ta lång tid att få fram en slutlig kravspecifikation om KO och PA har delade åsikter och krav på vad systemet ska innefatta. Specifikationen kan också bli dåligt utformad så att kraven på systemet inte framgår ordentligt. Effekt Hela projektet kommer att bli försenat vilket gör att PA kanske inte blir klara i tid. En dålig specifikation kan leda till att det slutliga systemet inte uppfyller de krav som KO hade tänkt sig. Åtgärd Diskutera igenom den preliminära specifikationen ordentligt med KO. Se till att den slutgiltiga specifikationen blir klar så fort som möjligt så att det övriga arbetet kan komma igång. Risk Dålig kommunikation inom PA kan göra det svårt att dela upp arbetsuppgifterna på ett bra sätt. Effekt Arbetet kommer att dra ut på tiden, kännas tråkigt och bli svårt att utföra enligt kraven. Åtgärd Många möten och tydlig dokumentation av allt som görs minimerar missförstånd. Risk: Systemet kan bli dåligt utformat och/eller har dålig dokumentation. Effekt: Support kommer att krävas, vilket PA inte kommer att kunna ge. Åtgärd: Designen av databasen måste göras på ett genomtänkt sätt. Dokumentationen måste göras lättläst och innehålla all nödvändig information för den person som ska sköta underhållet av systemet. Risk: Systemet kanske inte blir tillräckligt användarvänligt. Effekt: Systemet kommer inte att komma till användning. Åtgärd: PA måste lägga ner tillräckligt med tid på gränssnittets design och diskutera med de blivande användarna under arbetets gång. 9

Appendix A Egenskaper för objekt 1. Objektsbenämning 2. Obundna objekt 3. Standardmateriel 4. Handrekvisita 5. Inventarienummer 6. Enhet / avd 7. Hanteras av 8. Grupp 9. Antal 10. Form / typ 11. Motiv 12. Mått 13. Vikt 14. Material 15. Färg 16. Stil 17. Ålder 18. Design 19. Tekniska egenskaper 20. Kondition 21. Anmärkning 22. Tillverkningsår 23. Inköpsår 24. Inköpspris 25. Värde 26. Förrådsplats 27. Förrådsansvar 28. Lager 29. Noteringar 30. Kasserad år 31. Kategori Appendix B Egenskaper för bokade objekt 1. Akt 2. Bild 3. Rå 4. Position 5. Bokstav Appendix C Egenskaper för bokning 1. Föreställning 2. Premiärdatum 3. Spelplats 4. Regissör 5. Scenograf 6. Koreograf 7. Kostymer eller kostymtecknare 10

Bilaga 1 Systemskiss Databas Server Databaskoppling JDBC Applikationsserver TOMCAT 3.3 Webserver APACHE Användare HTMLdokument Klientdator 11