2D1954 Programutvecklingsprojekt Användning av handdatorer och trådlösa nät på föreläsningar och i labsalar Preliminär specifikation Malin Abrahamsson, I-99 Anders Back, I-99 Robert Bongart, I-99 Paula Bröms, I-99 Sara Jonsson, I-99 Daniel Larsson, I-99 Håkan Normark, I-99
1 Problembeskrivning Syftet med detta projekt är att undersöka huruvida handdatorer och/eller trådlösa nät kan användas i undervisning. För att undersöka aktuella möjligheter inom området, kommer stor vikt att läggas på teori- och litteraturstudier. Vidare kommer vi att undersöka vilket programspråk som är bäst att använda (Java, C++, Visual Basic, m fl.), vilken hårdvara som ska användas, vilken kapacitet nätverken för trådlös kommunikation på KTH har samt övrigt som är av vikt för vårt projekt. Vi kommer sedan att tillämpa ovanstående resultat och slutsatser på någon lösning. Vi kommer att koncentrera oss på att utveckla en modifierad och utökad version av det redan existerande programmet q-manager. Detta program fungerar som en väntelista för hjälp och redovisning i undervisningssammanhang. 1.1 Bakgrund Handdatorn har blivit mer än bara en elektronisk almanacka eller ett anteckningsblock. Dagens handdatorer har ett brett användningsområde och används i allt fler sammanhang. Handdatorer har flera fördelar. De är tillräckligt lätta och kompakta för att bära med sig. Vidare kan man utbyta information med stationära datorer. Dessa fördelar medför att handdatorer skulle lämpa sig väl i en undervisningssituation. Därtill ökar möjligheterna då man har tillgång till ett trådlöst nätverk. 1.2 Syfte Syftet med detta projekt är att undersöka huruvida handdatorer och/eller trådlösa nät kan användas i undervisning. För att åstadkomma detta kommer vi att utgå från idén till det idag redan existerande programmet q-manager som används för att hantera redovisningar i datorsalar. Med utgångspunkt från q-manager kommer vi att undersöka möjligheterna att utveckla ett program som kan användas trådlöst med handdatorer och avsevärt underlätta köhantering samt inrapportering av resultat vid laborationer i KTH:s datorsalar. Vidare vill vi eventuellt undersöka möjligheterna att även använda andra tekniker, såsom GPS och röststyrning, för detta ändamål. Observera att vi för tillfället befinner oss på en test- och utvärderingsnivå vad gäller hård- och mjukvara. Resultaten av dessa studier kommer i hög grad att påverka vår slutprodukt. 1.3 Krav och avgränsningar Funktioner Med hjälp av handdatorer ska lärare och assistenter kunna övervaka kölistor samt eventuellt kunna rapportera in studenternas resultat. 2
1.4 Datormiljön Hårdvara I projektet kommer vi att använda oss av en ipaq handdator och kommer därför att vara begränsade av dess funktioner. Programmeringen kommer att ske på en stationär dator. Handdatorn kommer att kunna kommunicera i KTHs trådlösa nätverk. Förutom handdatorerna kommer systemet i datorsalarna att kräva en server där alla gemensamma data kan lagras. Denna kommer att vara spindeln i nätet i vårt system. Mjukvara Mjukvarualternativen kommer att undersökas. Som operativsystem kommer såväl unix (linux) som Windows att testas. Vidare kommer vi att undersöka vilket programspråk som är bäst att använda (Java, C++, Visual Basic, m fl.) 2 Förslag till lösning Då litteraturstudier utgör en stor del av projektet är det svårt att specificera en lösning innan dessa är avslutade. Vi kommer dock att i vårt projekt preliminärt att utgå från nedanstående modell och undersöka kommunikationen mellan handdator och kölisthanterare. Q-manager fungerar på så sätt att en server startar en tråd för varje klient som tar kontakt (elevdator). För varje kurs startar en kölista som uppdateras när det kommer meddelande från klienterna. Dessutom körs en minuttråd som sover en minut i taget och sedan skickar ut en ny uppdaterad kölista med väntetiderna. SERVER KLIENTTRÅD MINUTTRÅD Användare Möjliga användare är lärare och assistenter som deltar i olika typer av laborationsundervisning. KÖLIST- HANTERARE KLIENT 3
3 Tidsplanering och administration 3.1 Övergripande tidsplanering Eftersom vårt projekt (enligt ovanstående punkter) är uppdelat i två delar, undersökning av tillgänglig hård- och mjukvara, försvåras vår tidsplanering, då det är svårt att exakt uppskatta tidsåtgången för teoristudierna. En annan faktor som spelar in är att vår slutprodukt i nuläget inte går att specificera direkt. Även detta resulterar i att en exakt tidsplanering är svår att åstadkomma. Med tanke på ovanstående kommer utvecklingen av vårt projekt att basera sig på en iterativ modell. Vi anser att Extreme Programming (XP) fungerar väl för vårt projekt. Dock ges nedan ändå en preliminär och grov tidsplanering. 8 mars Inlämning av denna specifikation. Under tiden fram till den 8 mars bedrivs även teoretiska studier av utrustning, programmeringsspråk m.m. P.g.a. tentamensperiod kommer detta arbete dock inte kunna intensifieras förrän efter den 8 mars. Vi håller dock löpande kontakt med vår uppdragsgivare som samtidigt som vi försöker sätta sig in i litteratur rörande ämnet. 20-22 mars En deltagare ur gruppen träffar kursledaren för lägesrapport. Målet är att till detta datum ha en klar bild av hur vi ska använda oss av den hård- och mjukvara som finns tillgänglig. Detta är viktigt inte minst eftersom det antagligen kommer att behövas köpas in viss utrustning. Detta måste aviseras i tid så att det inte blir en hindrande faktor att vi inte har någon utrustning. april Vår avsikt är att under första halvan av april månad helt kunna ägna oss åt arbetet med den specifika uppgiften. Några exakta hållpunkter för när olika delar av projektet skall vara klara är omöjliga att fastställa i nuläget. Enligt punkten 3.3 kommer dokumentationsarbetet i största möjliga mån att ske parallellt för att undvika en för stor arbetsbörda precis innan avslutningen av projektet. 3 maj Första tillfälle för slutredovisning projekt, dokumentation, användarhandledning m.m. skall vid denna tidpunkt vara helt slutfört. 3.2 Detaljplanering och aktiviteter Nedanstående lista är en mycket preliminär uppskattning av tidsåtgången per gruppmedlem för respektive aktivitet. Naturligtvis beror varje enskild gruppmedlems arbetsbörda inom respektive område på vilket ansvar denne har inom gruppen. Litteraturstudier (10h) Undersökning av hård- och mjukvara (10h) Fastställande och planering av projektuppgift (5h) Införskaffning av nödvändig utrustning 4
Implementation (30h) Testverksamhet (10h) Kompletterande implementation (15h) Slutförande av dokumentation (10h) Slutförande av användarhandledning (5h) Förberedelser inför slutredovisning (5h) Förutom ovanstående punkter genomförs löpande dokumentationsarbete, ordnas möten med uppdragsgivaren samt informella möten inom gruppen. Möten med uppdragsgivaren kommer att ske kontinuerligt, enligt XP-modellen, där uppdragsgivaren presenterar s.k. stories, vi diskuterar dessa, beslutar oss för vad som ska implementeras, testar, ändrar, utvidgar o.s.v. 3.3 Administration Organisation Organisationen inom gruppen är inte statisk och kommer att förändras med tiden. Eftersom arbetsuppgifterna skiftar under projektets gång kommer även organisationen att göra så. För närvarande, under perioden då vi studerar teori och utrustning, har vi ingen inbördes organisation förutom gruppledare, dokumentationsansvarig (som ansvarar för att löpande dokumentation genomförs, protokoll från möten uppförs m.m.) samt kontaktansvarig (som ansvarar för kontakten med kursledningen, uppdragsgivaren samt gruppmedlemmarna). När vi under andra halvan av mars kommer in på mer konkreta uppgifter kommer ytterligare uppdelning av ansvar att göras inom gruppen och poster som programmeringsansvarig m.fl. att utses. Möten Förutom regelbunden kontakt med uppdragsgivaren via e-mail och spontana möten kommer ett antal organiserade möten, där alla gruppmedlemmar samt uppdragsgivaren deltar, att ordnas. Vi har hittills genomfört två sådana möten (protokoll finns att tillgå på projektarean). På dessa möten gör vi upp en plan för den närmsta tidens arbete och diskuterar problem och frågeställningar som uppkommit sedan det senaste mötet. 3.4 Dokumentation För närvarande utgörs dokumentation av de protokoll som förs vid mötena samt naturligtvis de delar av denna preliminära specifikation som är tillämpbara. Inte förrän vårt arbete med en konkret uppgift kommer igång kommer det att vara möjligt att dokumentera. Det är viktigt att poängtera att det i dagsläget är osäkert huruvida vårt projekt kommer att resultera i en färdig, körbar och tillämpbar produkt. Om så inte är fallet kommer vår dokumentation att se annorlunda ut än vad som beskrivs nedan. Dokumentationsarbetet kommer att ske på följande sätt: En dokumentationsansvarig utses som bär det övergripande ansvaret för att dokumentationsarbetet utförs av berörda gruppmedlemmar. En person ansvarar för att all dokumentation som görs sammanställs. 5
De som huvudsakligen ägnar sig åt mjukvaruutveckling dokumenterar löpande sitt arbete och överlämnar dessa utkast till dokumentationsansvarige. Arbetet med sammanfattning av projektet, körexempel, referenser samt exakt systembeskrivning kommer att påbörjas mot slutet av kursen. Dessa delar av dokumentationen är svåra att påbörja innan stora delar av projektet är slutfört. Under mars/april kommer vid behov ett handledningstillfälle att bokas in med Ola Knutsson för att diskutera eventuella problem med dokumentationen. Våra ledord för dokumentationsarbetet är Dokumentera löpande!. Även arbetet med användarhandledningen och systembeskrivningen inkluderas i det ovan sagda. Användarhandledningen kommer ju att bestå av en delmängd av dokumentationen med tillägg. 4 Riskanalys Det finns alltid en viss risk att projekt inte riktigt utfaller enligt önskemål. I vårt fall är kanske denna risk än större då vi som grupp har väldigt liten erfarenhet av att arbeta i mjukvaruutvecklingsprojekt. Därtill har vi mycket begränsad erfarenhet av det teknikområde vi kommer att arbeta med, därför blir riskanalysen givetvis ännu svårare att genomföra. De risker vi redan nu kan se är emellertid (rangordnande efter potentiell skada de kan åstadkomma): 1. Risk: Vårt projekt är uppdelat i två delar, dels att undersöka vad den teknik vi arbetar med kan åstadkomma och dels implementera en tillämpning av densamma. På grund av detta löper vi risken att tekniken inte visar sig klara av det vi i utgångsskedet förutsatte. Det skulle få till följd att den uppgift vi uppfäst oss att lösa inte kan lösas med den teknik vi tänkt oss. Givetvis skulle detta resultera i att vår färdiga produkt aldrig blir klar eller att den blir kraftigt försenad. Lösning: För att råda bot på detta krävs nog att vi lämnar öppningar i specifikationen vilka kan spikas på en senare stadium då vi säkert vet vad tekniken kan hantera. 2. Risk: Som redan nämnts har alla projektdeltagare ringa eller ingen erfarenhet av den aktuella tekniken. Det kan resultera i att inlärningen av tekniken blir svårare än vad som uppskattats och därför tar längre tid än väntat. Projektet risker därför att försenas. Lösning: Genom att tidigt läsa på om och testa tekniken bör svårighetsnivån snabbt kunna uppskattas och lämplig tid avsättas. 3. Risk: Visserligen finns det i gruppen utdelat olika ansvarsområden. Ändå är dessa inte så fasta som de är på ett företag. Alltså finns en risk att uppgiftsdelegeringen och ansvaret för olika deluppgifter blir vag. Lösning: Varje gruppmedlem görs på det klara med vad han eller hon ska göra samt att projektet under inga omständigheter får försenas, något som skulle leda till att projektet inte slutförs innan terminens slut och därför troligen aldrig. 4. Risk: Eftersom projektet ska arbeta med handdatorer gäller det att sådana finns till hands för att testa med. Även om det finns simulatorer som kan köras på en vanlig dator måste programvaran också testas skarpt. Redan nu har en viss materialbrist kunnat skönjas och det är av yttersta vikt för projektets framgång att gruppen får tillgång lämpligt material. 6
Lösning: Om uppdragsgivaren tidigt informeras om materialsituationen kan han förmodligen se till att material finns till hands i god tid. 5. Risk: Eftersom gruppen som helhet har liten erfarenhet och kompetens inom teknikområdet är det att uppdragsgivaren finns till hands för att ge råd och hjälp om gruppen kör fast. Lösning: I realiteten kan man hoppas att denna risk är liten eftersom uppdragsgivaren dagligdags vistas på skolan och därför borde gå att få tag på. 7