Preliminär specifikation

Transkript

1 PRUP, FairWay Preliminär specifikation Projekt 40. Navigationssytem för utställningsbesökare Uppdragsgivare: Mats Erixon, CITU Daniel Högberg, projektledare Åke Djärf, vice projektledare Magnus Johansson, sekreterare Kristoffer Andersson Lars-Ove Björkman Martin Björkman Magnus Johansson Tobias Wallin Av: Kristoffer Andersson Stockholm, 1 maj 2000

2 Innehåll 1 Problembeskrivning Bakgrund Syfte Krav och avgränsningar Allmänt Funktioner Datormiljö Användare Förslag till lösning Systemskiss Moduler Diagram Dataflödesdiagram Delsystemstruktur Skiss av användargränssnittet Tidsplanering Generellt Projektledning Kravspecifikation Avtal Analys Design Implementation Testning Presentation / slutrapport Riskanalys

3 1 Problembeskrivning Uppdragsgivarens formulering av projektet: Med hjälp av en inskannad karta över området, inlagda distanser, olika utställande bolag och deras verksamhetsområden, skapas en så optimal färdväg som möjligt genom utställningen. Ytterligare variabler är också möjliga att lägga in. 1.1 Bakgrund På stora mässor, så som CeBITs i Hannover, samlas flera hundra företag för att ställa ut sina produkter och tiotusentals besökare irrar omkring bland alla dessa utställare i ett desperat försök att hitta de som intresserar just dem. Enorma hallar, dålig skyltning och tidsbrist är faktorer som gör ett mässbesök mindre angenämt än vad det skulle kunna vara. När besökaren dessutom ställer sig frågan om han/hon inte går denna samma väg för fjärde gången är det något som inte stämmer. 1.2 Syfte Något måste göras åt den tidskrävande och uttröttande promenad, fram och tillbaka över hallar stora som fotbollsplan, som en del mässbesökare utsätts för. Ett enkelt och tydligt navigationssytem, som visar en approximativt optimal väg till de utställare som är av intresse för en viss person, skulle kunna vara till stor hjälp och nytta. Syftet med detta projekt är att först och främst skapa ett grundsystem som löser detta problem och som eventuellt skulle kunna byggas ut med diverse tillägg. Några exempel på sådana tillägg är gruppering och sökning av utställare efter bransch och produkt, alternativa gränssnitt mot användaren (WAP, Palm pilot) och automatiserad mässkartstolkning för enklare administration av systemet. Projektet har även ett sekundärt, personligt syfte för projektmedlemmarna, som egentligen är av större vikt än det tidigare nämnda. Arbetet ska ge erfarenheter av projektarbete, dess processer, gruppdynamik, konflikthantering och ledning. Med andra ord hoppas vi att vi genom detta projekt vidgar våra vyer och får insyn i den arbetsmetodik som vi med stor sannolikhet kommer använda oss av i vårt framtida yrkesliv. Förutom dessa två viktiga syften har vi även enats om en högre målsättning för projektet. Visionen är att bli utnämnt till ett bästa projekt och att kunna presentera en världsledande mässruttplanerare. 3

4 1.3 Krav och avgränsningar För att kunna säkerställa att detta projekt blir genomförbart och användbart inom den tidsram som satts upp har vi blivit tvungna att ställa upp en del krav och avgränsningar på systemet. Dessa är satta på ett sätt som gör att de, om de följs, ger en minimal och generell lösning på problemet. Avsikten med att bara kräva en prototyp som resultat är att fokus ska ligga på basfunktionaliteten och att vi därefter ska kunna bygga ut systemet till en färdig produkt Allmänt Ett första krav är att engelska ska användas i all kod samt i alla leverans dokument. Systemet och koden måste dokumenteras noggrant och skrivas modulärt för att förenkla vidareutveckling av produkten. En användarhandledning måste givetvis skrivas, men systemet ska vara så intuitivt och enkelt att använda att det endast krävs en enkel hjälpfunktion vid eventuella problem Funktioner Systemet ska kunna läsa in statiska indata beskrivande mässan, företagen och deras position i mässlokalen. Användaren ska via ett grafiskt användargränssnitt kunna göra ett interaktivt val av utställare som han/hon önskar besöka. Detta följs av ett beräkningssteg och resultatet av detta presenteras i slutänden som en kortaste väg genom mässlokalen. Denna procedur måste kunna upprepas flera gånger under samma session. Tidsåtgången för beräkningssteget måste hållas under en rimligt låg gräns. Problemet är en variant av ett välkänt och beräkningstungt problem, nämligen TSP (Travelling Salesmans Problem). Detta innebär att lösningsförslaget med största sannolikhet måste begränsas till en approximation av den kortaste vägen. Funktionalitet och användarvänlighet ska dock sättas före prestanda. För att minimera tidsåtgången bör systemet göra lämpliga förberäkningar vid uppstart och inläsning av indatat Datormiljö Systemet ska vara ett Web-baserat enanvändarsystem, som enkelt kan byggas ut till ett fleranvändarsystem. Det måste vara robust, vilket innebär att om systemet byggs ut till ett fleranvändarsystem måste det, när så är praktiskt genomförbart, ta hänsyn till singlepoint failures, d.v.s. om en användare i en fleranvändarmiljö får problem skall detta inte låsa beräkningsmodulen för övriga användare. Genom att göra det Web-baserat blir systemet portabelt och inte bundet till någon speciell typ av operativsystem. Då budgeten för detta projekt tills vidare är mycket begränsad, bör utvecklarna så gott som det går hålla sig till det som är gratis. Utvecklingsspråk kommer med största sannolikhet vara Java. 4

5 1.3.4 Användare Den tänkta användargruppen för vårat navigeringssystem är mässbesökare. Mässarrangören kommer förstås också använda programmet för att läsa in mässbeskrivningen i systemet. 2 Förslag till lösning Efter ett majoritetsbeslut valde vi att inte presentera något lösningsförslag innan projektet kommit igenom analys- och designfasen. Vi ansåg att det var viktigt att inte rusa igenom denna första och mycket betydelsefulla del. Samtidigt vill vi inte låsa oss eller styra in oss mot någon lösning före problemet och alla lösningsförslag analyserats och utvärderats. Detta innebär att denna del kommer vara ganska tunn. 2.1 Systemskiss Moduler Mässnavigeringssystem Web interface Diagram Dataflödesdiagram Mässbeskrivning Val av platser Vägbeskrivning Mässnavigeringssytem Web Interface Administrator Mässbesökare 5

6 Delsystemstruktur PreCalc data Calc Datamodel Client Handler - HTTP -generic Controller PreCalc nod-id, koordinater (x,y), grannlista InfoHandler Base Data Base data Calc ClientHandler Controller Datamodel InfoHandler PreCalc PreCalc data Grundläggande information avseende en mässa/ utställning. Denna information består t.ex. av en karta över utställningsområdet, namn och beskrivning av alla utställare och koordinater för dessas fysiska placering i lokalen. Huvudsaklig beräkningsmodul. Denna modul beräknar den kortaste väg en besökare måste ta givet en lista över önskemål. Den delmodul som direkt kommunicerar med användaren. Kontrollmodul som givet en arbetsbegäran från ClientHandler begär beräkning av Calc-modulen. Uppläst grunddata för beräkning. En wrapper runt Base data. Tanken med denna modul är att säkerställa kontroll över det antal sessioner/ motsv som samtidigt är aktiva mellan ClientHandler och Base data. Administrationsmodul som i förväg utför vissa grundberäkningar. Lagrat utdata från PreCalc 6

7 2.1.3 Skiss av användargränssnittet 7

8 3 Tidsplanering 3.1 Generellt Då projektet är baserad på en kurs har det en mycket begränsad löptid. Det finns flera viktiga tidpunkter som måste hållas, som projektets tidplan har tvingats anpassa sig till. De deadlines som finns är markerade i tabellen nedan. Den sammanlagda tidsåtgången beräknas uppgå till cirka 750 timmar. Vecka Ledning Kravspec. Avtal Analys Design Impl. Test Present. 3.2 Projektledning I projektledning ingår att planera och driva projektet framåt, fördela arbetsuppgifter, koordinera samt tidsplanera. Projektledaren ansvarar också för kontakterna med uppdragsgivaren. Dokument: Projektplan där uppgifter och tider beskrivs. Milstolpar: Projektet skall fullföljas till redovisningen som hålls senast den 19 maj Tidsåtgång: 80 timmar, fördelat över hela projektet Ansvarig: Daniel Högberg 3.3 Kravspecifikation Eftersom uppdragsgivaren, Mats Erixon, bara har en generell önskan om projektets resultat, är vi tvungna att själva framställa en 8

9 kravspecifikation. Denna blir då en mer omfattande beskrivning av vad vi vill få gjort med projektet. Dokument: Kravspecifikation som beskriver vad systemet skall göra. Milstolpar: Delar ur kravspecifikationen bildar tillsammans med delar av analysen den preliminära specifikationen som ska inlämnas till Lars Kjelldahl senast den 10 mars Tidsåtgång: 30 timmar Ansvarig: Kristoffer Andersson 3.4 Avtal För att reglera rättigheter till hela eller delar av resultaten från projektet kommer avtal att skrivas dels mellan projektgruppens medlemmar och dels mellan projektgruppen och uppdragsgivaren. Dokument: Ett avtal för projektgruppens medlemmar och ett mellan projektgruppen och uppdragsgivaren. Milstolpar: Senast den 2 mars 2000 skall avtalet gentemot uppdragsgivaren skrivas under. Avtalet inom gruppen skall skrivas under innan avtalet gentemot uppdragsgivaren skrivs under. Tidsåtgång: 30 timmar Ansvarig: Martin Björkman 3.5 Analys För att ta reda på vad vi ska göra samt hur detta ska göras (på ett generellt plan) undersöks i denna fas vad som finns att tillgå inom olika tekniker, datakällor o.s.v. Dokument: Scenarion ("Use cases") i textform, skiss av användargränssnitt, skiss av arkitektur. Milstolpar: Eftersom delar av analysens resultat ska lämnas in tillsammans med specifikationen till Lars Kjelldahl, måste analysen vara klar till den 10 mars Tidsåtgång: 40 timmar Ansvarig: Kristoffer Andersson 3.6 Design För att implementationen ska bli smidig och rätt från början gäller det att lägga stor vikt vid hur projektgruppen väljer att utforma det slutgiltiga systemet. Dokument: Arkitekturell design av systemet, detaljspecifikation av alla gränssnitt samt vilka algoritmer som ska användas, beskrivning av databasstruktur (eller liknande). Milstolpar: All designdokumentation måste vara framtagen till etappredovisningen som ska vara senast den 12 april Tidsåtgång: 150 timmar Ansvarig: Åke Djärf 9

10 3.7 Implementation Implementation av systemet enligt detaljspecifikation. Det skall även ske enhetstester utifrån testprotokoll. Systemet ska också dokumenteras och göras användarvänligt i form av användarhandbok. Dokument: Programkod som utgör ett körbart system, systemhandbok som beskriver systemet och kraven på datormiljö, användarhandbok. Milstolpar: Allt ska vara klart till 1 maj 2000, för att tester skall hinna göras fram till den 4 maj 2000 då förhandsvisning av systemet skall ske. Tidsåtgång: 240 timmar Ansvarig: Martin Björkman 3.8 Testning För att kunna avsluta projektet måste man kunna kontrollera att resultatet uppfyller alla tidigare uppsatta mål eller dokument. Detta innebär således kontroll av allt framställt material så att det överensstämmer med tidigare material. Dokument: Plan och protokoll för enhetstest, integrationstestplan. Milstolpar: Enhetstesterna utförs under implementationen, planerna måste därför vara klara till den 5 april Integrationstesterna kommer att genomföras dagarna efter att implementationen är klar, d.v.s. de första dagarna i maj fram till den 4 maj Tidsåtgång: 100 timmar Ansvarig: Lars-Ove Björkman 3.9 Presentation / slutrapport För att kunna 'sälja' projektets resultat måste en övertygande presentation framställas. Dokument: Presentation för dator och OH. Milstolpar: Till förhandsvisningen måste presentationsmaterial vara klart, d.v.s. till den 4 maj Tidsåtgång: 80 timmar Ansvarig: Tobias Wallin 10

11 4 Riskanalys I ett försök att kartlägga vad som skulle kunna gå snett har vi här angivit vår uppskattade sannolikhet att en viss händelse inträffar samt vilka eventuella konsekvenser som skulle kunna uppstå, efter skalan Hög/Medel/Låg. Risk Konsekvens Problem Åtgärd H H Prestanda- eller nogrannhetsproblem med algoritmen för TSP. Undersöka flera metoder. Förenkla problemet. Se över approximationsmöjligheter och graden av approximation. M H Tidsbrist p.g.a. att andra kurser tar mycket tid. Jobba hårt i början. Arbeta fram en tidplan alla tror på och känner sig delaktiga i. M L M H Kunskapsbrist i gruppen. Datormiljöproblem. Kan vi få tag i vad vi behöver gratis? Mindre områden: kontakta andra som kan. Större saker: omformulera eller begränsa kraven. Undersök på ett tidigt stadium vad gruppen behöver. Håller CITU med någon utrustning? Omforma kraven. L H Samarbetsproblem inom gruppen. Tag genast upp problem. Diskutera, kanske omfördela arbetsuppgifter. L L Sjukdom / semester för gruppmedlem. Alla måste tala om längre planerad frånvaro. Omprioritera / omstrukturera. 11