Matematikdidaktik. 1DV411 Webbprojekt I

Transkript

1 Matematikdidaktik 1DV411 Webbprojekt I Författare: Jennifer Nord, Nils Jakob Olsson, Svante Arvedson, Maria Nygren, Christoffer Holmgren och David Söderberg Handledare & examinator: Tobias Olsson Termin: VT15

2 Sammanfattning Målet med projektet var att skapa en applikation för användning i matematikundervisning i förskolan och lågstadiet. Projektet syftade också till att vi som studenter skulle lära oss grupparbete och projektdynamik. Vi har i projektet haft en fast rollfördelning men alla har deltagit i arbetets alla moment. Arbetssättet har varit en kombination av Unified Process och SCRUM. Varje vecka har vi haft ett möte med vår handledare. Vi har haft kontinuerlig kontakt med vår kund och leverans har skett varje vecka. Applikationen har implementeras med HTML5 tekniker såsom WebGL, Javascript samt PHP. Vi lärde oss arbeta som grupp och projektet bedöms som lyckat av alla inblandade parter. Resultatet blev en fungerande applikation vid namn Kubus som publicerades på Karlstads Universitets server. 2

3 Innehållsförteckning Sammanfattning Innehållsförteckning Inledning Syfte och mål Projektorganisation Ansvarsfördelning Genomförande Metodik Teknik Resultat Slutdiskussion Positivt Negativt Förslag på vidareutveckling Förslag till förbättringar inför kommande projekt Bilagor 3

4 Inledning I matematikundervisningen på lågstadiet finns det ett behov av en byggklossapplikation som kan användas samtidigt som elever bygger och undersöker former med fysiska kuber. 1 2 Spelet Minecraft och applikationen Huisje bouwen har tidigare använts för detta. Med applikationerna har eleverna kunnat bygga och undersöka 3D former med hjälp av kuber. Den nederländska applikationen har många brister då den är skriven som en Java Applet som inte fungerar på moderna surfplattor och mobiler. Minecraft blir lek istället för lektion då eleverna blir distraherade av de övriga funktionerna som gör Minecraft till ett spel och inte ett undervisningsredskap. 3 Vi fick i uppdrag av Jorryt van Bommel, matematikdidaktiker på Karlstads Universitet, att bygga en ny liknande applikation med modern teknik som fungerar på olika sorters moderna enheter som eleverna i dagsläget har tillgång till. Applikationens användargränssnitt ska vara skrivet på svenska och applikationen ska fungera offline såväl som online. Den färdiga applikationen kommer att användas dels i undervisning av lärare i grundskolor men också i forskningssyfte av Jorryt van Bommel. 1 Minecrafts hemsida, 2 Huisje bouwen, 3 Karlstads Universitet angående Jorryt van Bommel, van bommel 4

5 Syfte och mål 4 Projektets syfte var fastställt i kursens kursplan och målet var att uppdragstagarna skulle få använda sig av kunskaper erhållna på Webbprogrammerarprogrammet och under projektets gång få: Analysera ett praktiskt problem och hitta olika förslag till lösningar. Välja lämplig lösning utifrån gällande förutsättningar. Genomföra ett projekt i grupp. Föra vedertagen projektdokumentation. Presentera sitt arbetssätt och resultat både skriftligt och muntligt. Målet var även att leverera en modern, fungerande och pedagogisk applikation till uppdragsgivaren som går att använda i utbildnings och forskningssyfte kring matematikundervisningen av barn mellan 6 10 år. För att målet skulle bli mätbart delades det in i 5 baskrav. BK1 Applikationen ska kunna användas offline. BK2 Applikationen ska kunna användas på mobila enheter som exempelvis ipads. BK3 Applikationen ska vara lätt att förstå och använda även för användare som inte kan läsa eller som inte har en god datorvana. BK4 I applikationen ska man kunna bygga med klossar. 4 Kursplan 1DV411 Webbprojekt I, hämtad från &documenttype=pdf&lang=sv 5 Vision, se bilaga. 5

6 Projektorganisation Rollfördelningen har under projektets gång varit statisk och varje ansvarsområde har varit bestämt sedan projektets start. Det har även i projektgruppen funnits en uppdelning i kodgrupp, gränssnittsgrupp och testgrupp där varje grupp har haft ett eget ansvarsområde där medlemmarna har roterat mellan grupperna. Ansvarsfördelningen beskrivs nedan. Diagrammet nedan visar hur hierarkin inom projektorganisationen har sett ut. Ansvarsfördelning Projektledaren har varit ansvarig för projektgruppen som helhet och bestämt vad som ska göras under varje iteration. Kundansvarige har varit ansvarig för kravinsamling och kundkontakt. Gränssnittsansvarige har ansvarat för gränssnittsgruppens arbete och att gränssnittet uppfyller kundens krav, det har även inneburit ett mindre ansvar för kundkontakt. Testansvarige har haft ansvar att granska testgruppens arbete och för att se till att applikationen testas ordentligt enligt testspecifikationen. Teknikansvarige har varit ansvarig för publicering av applikationen. Under projektets gång har alla provat att vara med i kod, gränssnitt respektive testgrupp. Kodgruppen har under iterationernas gång arbetat med att skriva front end kod och back end kod. De har även varit ansvariga för att skriva enhetstester till den nya kod som de själva har skrivit under iterationens gång. 6

7 Gränssnittsgruppen arbetade med, som namnet antyder, gränssnittet och allt som rör detta. Ikoner och CSS styling men även JavaScript kod som behövs för att gränssnittet ska fungera. Testgruppen har under projektetsgång varit ansvarig för att skriva nya testfall och att testa den aktuella versionen av applikationen. Gruppen har även skrivit testrapporter och sammanställt de problem som testerna har visat. 7

8 Genomförande Metodik En kombination av Unified Process och SCRUM har använts. Vokabulären är hämtad från 6 7 Unified Process. Iterationslängden har varit en vecka. Varje vardagsmorgon har vi haft en version av Daily Scrum och en gång varje vecka har vi haft handledningsmöte samt levererans till kund. Efter varje major milestone har en annan projektgrupp samt Emil Carlsson granskat vårt arbete och därefter gett oss återkoppling och förslag på förbättrningar. Arbetsgruppernas storlek och syfte har varierat mellan iterationerna efter vad iterationen har innehållit. För versionshantering har GitHub använts. Vi har använt oss av GitHubs issues för att rapportera problem med den aktuella versionen av applikationen och deras release tags för att kunna markera olika versioner av applikationen. Kommunikation inom gruppen har skett via Skype. Under inceptionfasen signerade kund vår vision och vi hade som grupp implementerat och undanröjt de största tekniska riskerna. Projektet kändes genomförbart med de resurser som fanns till hands och med tanke på riskerna som identifierades. Inceptionfasen avslutades en iteration tidigare än vad som var planerat. Då inceptionfasen avslutades tidigare än vad som var planerat kunde vi använda ytterligare en iteration åt elaborationfasen. Under den här fasen fastställdes mjukvaruarkitektur som även kunde levereras till kund. Alla tekniska risker var undanröjda och rutiner för testning var fastställda. När vi gick in i constructionfasen fanns det en stabil version av applikationen som vi kunde arbeta vidare med för att hitta buggar och finslipa gränssnittet. Efter constructionfasen var 6 Wikipedia om Unified Process, 7 Wikipedia om SCRUM, 8

9 mjukvaran utvecklad och färdig för slutleverans. Tillvägagångssättet för slutleverans till kund var också bestämt. Transition blev den avslutande fasen och vi använde den här tiden för att finslipa plattformsoberoende samt förbättra utseendet av applikationen. All dokumentation färdigställdes och vi testade applikationen noggrant och i slutet av fasen levererade vi den färdiga applikationen till kunden. Dokumentation som har tagits fram är vision, projektplan, iterationsplaner, risklista, kravspecifikation, mjukvaruarkitektur, tidsrapporter och källkod. Det finns även ytterligare dokumentation så som testfall och testrapporter samt en inledning som bör underlätta för utomstående läsare då den är tänkt att vägleda läsaren genom dokumentationen Teknik Den teknik som utmärker sig mest i projektet är WebGL där vi har valt att använda oss av 8 three.js som är ett 3D bibliotek i JavaScript. Three.js valdes på grund av sin fallback lösning då WebGL saknades som saknades i de andra bibliotek som vi undersökte. Anledningen till att vi valde ett bibliotek för 3D i JavaScript är främst för att vi annars hade behövt felsöka i flera olika plattformar om vi själva hade skrivit 3D renderingen. Vi använder oss även utav JQuery 9 som är ännu ett JavaScript bibliotek. Där har vi valt att använda version då den stöds av ett större antal plattformar än nyare versioner. JQuery används för DOM manipulation och eventhantering i gränssnittet. Applikationens back end del är ett PHP API där ramverket Silex 10 används för att det har den grund som vi har behövt och det har möjlighet att byggas ut med hjälp av Symfony2 11 moduler. För den persistenta lagringen användes JSON filer istället för en SQL databas. Vårt resonemang såg ut som så att det är mer framtidssäkert med en JSON fil. Eftersom vi har använt ett ramverk är det så att Silex kommer att behöva uppdateras emellanåt då det sker 8 Three.js hemsida, 9 JQuerys hemsida, 10 Silex hemsida, 11 Symphonys hemsida, 9

10 säkerhetsuppdateringar. Dock innehåller applikationen inte känslig data då modellerna endast lagras i 30 dagar och den innehåller ingen känslig användarinformation. 10

11 Resultat Syftet var att leverera en modern, fungerande och pedagogisk applikation, detta har vi lyckats med. Baskraven uppfylldes, applikationen går att använda offline och applikationen går att använda på en stor mängd mobila enheter. Användartestningen visade att applikationen gick att förstå utan läskunskap. Slutligen så kan man i applikationen bygga med klossar. Vi gjorde inga större avvikelser från vår vision utan allt levererades så som det var tänkt. Det enda vi inte lyckades med helt var plattformsoberoendet. Vi fick inte applikationen att fungera fullt ut på ios7 enheter. 12 Applikationen döptes till Kubus och ligger på Karlstad Universitets server. 12 Kubus, körbar applikation, 11

12 Slutdiskussion Positivt Tät kontakt mellan gruppens medlemmar gjorde att arbetet flöt på bra, problem som vi stötte på kunde vi lösa snabbt. Vi gick in i projektet med respekt för varandra och med en förståelse att alla inte alltid kan vara tillgängliga eller prestera på topp. Efterhand som vi lärde känna varandra bättre så hittade vi också våra styrkor respektive svagheter och kunde anpassa arbetsuppgifterna så att alla kunde göra sitt bästa. Vi höll den stora tidsplanen bra, vi levererade enligt de deadlines som var uppsatta. Vår dokumentation och användande av GitHub gjorde att vi hade koll på arbetsflödet och visste vad som skulle göra i varje iteration. Vi känner att instruktionerna och riktlinjerna vi fick både från vår kund och från kursledningen var bra och hjälpte oss att få struktur på arbetet. Testningen har fungerat bra och vi litar på att applikationen som vi levererar och de tekniska lösningar vi har valt kommer att fungera så som det är tänkt. Vår kund har fått applikationen leverad till sig varje vecka och har sagt sig vara nöjd med slutprodukten. Vårt uppstartsmöte med hela projektgruppen och kunden gjorde att vi redan från början fick en bra kommunikation. Negativt Vi använde på Skype som ett av våra kommunikationsverktyg och detta ställde till en del problem. Skype fungerar inte smärtfritt, ofta bryts samtal eller så är det svårt att höra varandra och morgonmötena har ibland upplevs som sega på grund av detta. Även skärmdelning och fildelning har varit svårt, funktioner som är viktiga i ett sånt här projekt. I starten av projektet var vi inte speciellt vana att koda i grupp. Bristen på rutin gjorde att kodfilerna i starten av projektet lätt blev röriga och onödiga buggar uppstod. Efterhand som projektet fortskred så fick vi mer rutin på arbetet men vissa filer är fortfarande lite röriga. 12

13 Omkring iteration 6 hade vi en svacka i kommunikationen och arbetsflödet, och arbetet var därför mindre produktivt den veckan. Vi löste problemen genom samtal och diskussioner. Den kortsiktiga planeringen brast ibland. Vi skattade ofta mer tid än vad arbetsuppgifterna egentligen tog och ibland hann vi inte med alla arbetsuppgifterna vi hade listat i iterationsplanerna. Vi har separata dokument för tidrapporter och iterationsplaner och tidsangivelsen skiljer sig lite mellan de olika dokumenten. 13

14 Förslag på vidareutveckling Applikationen kan vidareutvecklas på många olika sätt. Nedan nämns några funktioner som kan tänkas vara intressanta för framtida vidareutveckling. Användaren får en bild, som agerar som mall, att bygga efter. När användaren har lyckats återskapa bilden/skapa byggnaden i mallen så visar applikationen ett rättmeddelande som talar om att användaren har lyckats återskapa byggnaden. Vi tänker att detta kan vara en funktion av pedagogisk betydelse. En annan funktion som kan ha pedagogisk betydelse är att användaren får se en byggnad och därefter ska uppskatta antal kuber som har använts för att skapa byggnaden. Detta kan man se som ett extra läge som man skulle kunna ställa in applikationen på. Applikationen låter användaren välja en vy och därefter roteras den stora modellen till det perspektiv som den valda vyn visar. Applikationen skulle kunna kopplas till en 3D skrivare och lägga till funktioner för att få det att fungera hade varit intressant. Även att applikationen skulle vara kopplad till fysiska kuber och på så sätt få applikationen att visa det som sker i den fysiska världen. Applikationen skulle kunna optimeras när det gäller gränssnitt och prestanda. Gränssnittet går att förbättra så att det bättre uppfyller kraven om plattformsoberoende. 14

15 Förslag till förbättringar inför kommande projekt Som distansgrupp så har de verktyg vi har valt att använda för kommunikation och versionshantering haft en stor roll. I framtida projekt kommer vi att undersöka andra verktyg än Skype för muntlig kommunikation då vi känner att Skype har varit ett för ostabilt verktyg. Att dela skärm har fungerat mindre bra och det är starkt rekommenderat att använda ett Adobe Connect rum för att dela med sig av skärm. Ett annat verktyg som kan vara intressant att prova istället för Skype är Google Hangouts. Att använda GitHub för versionshantering har varit mycket uppskattat inom gruppen. GitHubs Issues har för oss fungerat som en product backlog. I framtiden så vill vi själva lära oss använda wiki pages som finns på GitHub så man kan samla dokumentation och kod på ett och samma ställe. Försök att använda verktyget fullt ut! För kommunikationen bestämde vi oss för att ha Daily Scrum varje vardagsmorgon. Detta gjorde att alla inom gruppen har haft vetskap om aktuell projektstatus och information men också kunnat reflektera under arbetets gång. Under en av iterationerna kände vi av en arbetssvacka och Daily Scrum gjorde det möjligt för oss att prata om problemet. Man får inte vara rädd för att uttrycka missnöje eller oro då det förmodligen finns fler i gruppen som känner likadant. Värt att tänka på inför kommande projekt är även arbetsbelastningen och arbetsfördelningen. För många i gruppen har det inte varit ett jämnt flöde. Detta kan bero på vår strikta arbetsfördelning mellan kodning, testning och gränssnitt som har gjort att vissa av oss inte har kodat, testat eller arbetat med gränssnittet så mycket. Vi har dock fått utrymme att göra det som vi personligen tycker om. Det är också viktigt att på individnivå inte göra allt på en gång. Det är lätt att tappa intresset för projektet om man har dragit en tyngre last i början. Tidrapporteringen är också något som man bör komma överens om tidigt. Hur noggranna man ska vara, vad som ingår samt hur man tänker kring minuter och timmar. Ett viktigt råd som vi kan ge kommande projektgrupper är att inte tvinga andra i gruppen att ta en roll om de inte är intresserade av det. Vi tror även att man tappar mycket kraft och kunskap när man sitter på en roll mot sin vilja och därför valde vi att ha en fast rollfördelning. Vi vann kunskap, motivation och självkänsla genom att behöva lära sig de olika delarna i början av 15

16 projektet då vi roterade mycket inom de mindre grupperna. I slutet av projektet övergick vi mer till en fast arbetsfördelning. Att ha en kundansvarig har bidragit till god kundkontakt och kunden har upplevt det som bra. Att börja med testning tidigt har varit viktigt för att skapa en stabil applikation och vi har hunnit med sju omgångar med testning, inklusive användandetestning. Detta för att vi tidigt skrev en tydlig och färdig testspecifikation. Användbarhetstestningen upplevde vi som väldigt positivt och det är en upplevelse vi tar med oss till kommande projekt. Finns det ett icke funktionellt krav så som plattformsoberoende så blir testningen något utav det viktigaste att göra på så många enheter som möjligt. 16

17 Bilagor Kursplan 1DV411 Webbprojekt I, hämtad Vision 17

18 Iterativ mjukvaruutveckling Objektorienterad Analys och Design Kunskaper i XHTML alternativt XML Kunskaper i databasmodellering och objektorienterad serversideprogrammering, t.ex. ASP.NET eller php. Kursplan Fakultetsnämnden för naturvetenskap och teknik Institutionen för datavetenskap, fysik och matematik 1DV411 Webbprojekt I, 7,5 högskolepoäng Web Project I, 7.5 credits Huvudområde Datavetenskap Ämnesgrupp Informatik/Data och systemvetenskap Nivå Grundnivå Fördjupning G1F Fastställande Fastställd av institutionsstyrelsen vid Institutionen för datavetenskap, fysik och matematik Senast reviderad Revidering för engelsk översättning av kursplan, förkunskaper och kursvärdering. Kursplanen gäller från och med vårterminen 2011 Förkunskaper ASP.NET Webforms (1DV406), 7,5 hp, ASP.NET MVC (1DV409), 7,5 hp eller Webbutveckling med PHP (1DV408), 7,5 hp samt Objektorienterad Analys och Design med UML (1DV407), 7,5 hp eller motsvarande. Förväntade studieresultat Efter kursen skall studenten kunna: analysera ett praktiskt problem och hitta olika förslag till lösningar välja lämplig lösning utifrån gällande förutsättningar genomföra ett projekt i grupp föra vedertagen projektdokumentation presentera sitt arbetssätt och resultat både skriftligt och muntligt Innehåll Kursen drivs i projektform med handledare i de ämnesområden som programmet omfattar. Viktiga komponenter i projektet är: Teoretiska förutsättningar

19 Teoretiska förutsättningar Iterativ mjukvaruutveckling Objektorienterad Analys och Design Kunskaper i XHTML alternativt XML Kunskaper i databasmodellering och objektorienterad serversideprogrammering, t.ex. ASP.NET eller php. Genomförandet Projektledning och projektplanering Projektdokumentation Mål och målgruppsanalys Presentationen Att presentera teknisk information på ett begripligt och förståeligt sätt anpassat till aktuell målgrupp Seminarie med presentation av det färdiga materialet Undervisningsformer Kursupplägget använder internet som distributionsform och kan läsas antingen på campus eller på distans. På campus består undervisningen i form av nätbaserat material, föreläsningar, handledningsmöten och seminarier. I distansundervisningen består kursen av nätbaserat material, handledningsmöten samt avslutande seminarium och projektpresentation på institutionen. Examinationsformer Kursen bedöms med betygen U,3,4 eller 5. För ett godkänt betyg krävs aktivt deltagande i projektarbetet, genomfört och presenterat projekt inklusive godkänd dokumentation. Obligatorisk närvaro vid projektmöten. Student vid Linnéuniversitetet har rätt att få sitt betyg för kurs översatt till den sjugradiga ECTSskalan. För att få sitt betyg översatt ska studenten lämna en begäran om detta till läraren vid kursstart. Omexamination erbjuds inom sex veckor inom ramen för ordinarie terminstider. Antalet examinationstillfällen är begränsat till fem gånger. Kursvärdering I samband med kursavslutningen genomförs en kursvärdering enligt universitetets riktlinjer. Resultatet av kursvärderingen arkiveras på institutionen. Övrigt Kursen förutsätter minst 60 hp inom programmet Webbprogrammerare, varav minst 45 hp datavetenskap. Kurslitteratur och övriga läromedel Obligatorisk litteratur Nätbaserat material som anges på kursens webstudieplats. Referenslitteratur Lööw, M. (2003) Att leda och arbeta i projekt. Liber AB. ISBN: X TNC 100 (Senaste upplagan) Skrivregler för svenska och engelska från TNC. Terminologicentrum TNC. ISBN: Med reservation för ändringar i litteraturförteckning.

20 Vision Matematikdidaktik Problem/Bakgrundsbeskrivning I matematik undervisningen på lågstadiet finns det ett behov av en byggklossapplikation som kan användas samtidigt som elever bygger och undersöker former på riktigt med fysiska kuber. Spelet Minecraft och applikationen har tidigare använts för detta. I de här applikationerna har eleverna kunnat bygga olika 3D former med hjälp av kuber och undersöka formerna. Den nederländska applikationen har många brister då den är skriven som en Java Applet som inte fungerar på moderna surfplattor och mobiler. Minecraft blir lek mer än lektion då eleverna är mycket medvetna om de övriga funktionerna som finns i spelet och lätt blir distraherade. Uppdraget är att bygga en ny liknande applikation med modern teknik som fungerar på olika sorters moderna enheter som eleverna i dagsläget har tillgång till. Applikationens användargränssnitt ska vara skrivet på svenska och applikationen ska fungera offline såväl som online. Användare Förskoleklass och lågstadielärare Lärare på förskolan och lågstadiet kan använda applikationen när de undervisar sina elever i matematik. Det pedagogiska syftet med applikationen är att visa sambandet mellan byggandens sidovyer och själva byggnaden. Gruppen vill ha en applikation som går snabbt att lära sig att använda, de vill inte lägga ner tid för att lära sig olika funktioner eller för att läsa instruktioner. Förskoleklass och lågstadieelever (5 10 år gamla) Elever i förskolan och lågstadiet kan använda applikationen som ett hjälpmedel i sina matematikstudier. De ska fritt eller enligt instruktioner kunna bygga byggnader och undersöka byggnadernas sidovyer. Många i den här användargruppen kan inte läsa och skriva ännu, den grafiska utformningen av applikationen måste anpassas till detta. Liknande applikationer Block Builder 3D I den här applikationen kan man bygga byggnader men man ser inga sidovyer. Applikationen innehåller dessutom andra funktioner som stör elevernas fokus på uppgiften. builder 3d free/id ?mt=8 Play Toy Block toy block lite/id ?mt=8 Intressenter Jorryt van Bommel Karlstads Universitet Beställare av applikationen. Arbetar med matematikdidaktik på Karlstads Universitet.

21 Matematikdidaktiker Andra av samma yrke som Jorryt van Bommel, beställaren av applikationen. Valda tekniker Applikationen ska byggas som en webbappliaktion som också ska kunna användas offline. Applikationen ska skrivas i språken HTML5, CSS och JavaScript. Applikationen ska byggas med hjälp av javascriptramverket Three.js. Baskrav BK1 Applikationen ska kunna användas offline. BK2 Applikationen ska kunna användas på mobila enheter som exempelvis IPads. BK3 Applikationen ska vara lätt att förstå och använda även för användare som inte kan läsa eller som inte har en god datorvana. BK4 I applikationen ska man kunna bygga med klossar.