Embed Size (px)
Citation preview
Matematikdidaktik 1DV411 Webbprojekt I
Författare: Jennifer Nord, NilsJakob
Olsson, Svante Arvedson, Maria Nygren,
Christoffer Holmgren och David Söderberg
Handledare & examinator: Tobias Olsson
Termin: VT15
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
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
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.
Spelet Minecraft och applikationen Huisje bouwen har tidigare använts för detta. Med 1 2
applikationerna har eleverna kunnat bygga och undersöka 3Dformer 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.
Vi fick i uppdrag av Jorryt van Bommel , matematikdidaktiker på Karlstads Universitet, att bygga 3
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, https://minecraft.net 2 Huisje bouwen, http://www.fisme.science.uul.nl/toepassingen/00249 3 Karlstads Universitet angående Jorryt van Bommel, http://www.kau.se/forskare/jorrytvanbommel
4
Syfte och mål Projektets syfte var fastställt i kursens kursplan och målet var att uppdragstagarna skulle få 4
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 610 år. För att målet skulle bli mätbart delades det in i
baskrav . 5
● 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 20150319 från http://prod.kursinfo.lnu.se/utbildning/GenerateDocument.ashx?templatetype=coursesyllabus&code=1DV411&documenttype=pdf&lang=sv 5 Vision, se bilaga.
5
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 frontend kod och backend
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
Gränssnittsgruppen arbetade med, som namnet antyder, gränssnittet och allt som rör detta.
Ikoner och CSSstyling men även JavaScriptkod 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
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 releasetags 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, http://en.wikipedia.org/wiki/Unified_Process 7 Wikipedia om SCRUM, http://en.wikipedia.org/wiki/Scrum_%28software_development%29
8
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
three.js som är ett 3D bibliotek i JavaScript. Three.js valdes på grund av sin fallbacklösning då 8
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 som är ännu ett JavaScript bibliotek. Där har vi valt att 9
använda version 1.11.2 då den stöds av ett större antal plattformar än nyare versioner. JQuery
används för DOMmanipulation och eventhantering i gränssnittet.
Applikationens backend del är ett PHP API där ramverket Silex används för att det har den 10
grund som vi har behövt och det har möjlighet att byggas ut med hjälp av Symfony2 moduler. 11
För den persistenta lagringen användes JSONfiler istället för en SQL databas. Vårt
resonemang såg ut som så att det är mer framtidssäkert med en JSONfil. 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, http://threejs.org/ 9 JQuerys hemsida, http://jquery.com/ 10 Silex hemsida, http://silex.sensiolabs.org/ 11 Symphonys hemsida, http://symfony.com/
9
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
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.
Applikationen döptes till Kubus och ligger på Karlstad Universitets server. 12
12 Kubus, körbar applikation, http://www2.kau.se/jorrbomm/
11
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
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
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
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
Connectrum 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
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
Bilagor Kursplan 1DV411 Webbprojekt I, hämtad 20150319
Vision
17
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 20090623
Senast reviderad 20100820. 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:
l analysera ett praktiskt problem och hitta olika förslag till lösningar l välja lämplig lösning utifrån gällande förutsättningar l genomföra ett projekt i grupp l föra vedertagen projektdokumentation l 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
l Iterativ mjukvaruutveckling l Objektorienterad Analys och Design l Kunskaper i XHTML alternativt XML l Kunskaper i databasmodellering och objektorienterad serversideprogrammering, t.ex. ASP.NET eller php.
Genomförandet
l Projektledning och projektplanering l Projektdokumentation l Mål och målgruppsanalys
Presentationen
l Att presentera teknisk information på ett begripligt och förståeligt sätt anpassat tillaktuell målgrupp
l 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 presenteratprojekt inklusive godkänd dokumentation. Obligatorisk närvaro vid projektmöten. Studentvid 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ärarenvid 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: 914707308X TNC 100 (Senaste upplagan) Skrivregler för svenska och engelska från TNC. Terminologicentrum TNC. ISBN: 9171961003 Med reservation för ändringar i litteraturförteckning.
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 20090623
Senast reviderad 20100820. 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:
l analysera ett praktiskt problem och hitta olika förslag till lösningar l välja lämplig lösning utifrån gällande förutsättningar l genomföra ett projekt i grupp l föra vedertagen projektdokumentation l 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
l Iterativ mjukvaruutveckling l Objektorienterad Analys och Design l Kunskaper i XHTML alternativt XML l Kunskaper i databasmodellering och objektorienterad serversideprogrammering, t.ex. ASP.NET eller php.
Genomförandet
l Projektledning och projektplanering l Projektdokumentation l Mål och målgruppsanalys
Presentationen
l Att presentera teknisk information på ett begripligt och förståeligt sätt anpassat tillaktuell målgrupp
l 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 presenteratprojekt inklusive godkänd dokumentation. Obligatorisk närvaro vid projektmöten. Studentvid 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ärarenvid 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: 914707308X TNC 100 (Senaste upplagan) Skrivregler för svenska och engelska från TNC. Terminologicentrum TNC. ISBN: 9171961003 Med reservation för ändringar i litteraturförteckning.
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 http://www.fisme.science.uu.nl/toepassingen/00249 har tidigare använts för detta. I de här applikationerna har eleverna kunnat bygga olika 3Dformer 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 (510 å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. https://itunes.apple.com/se/app/blockbuilder3dfree/id519028914?mt=8
Play Toy Block https://itunes.apple.com/us/app/playtoyblocklite/id792040909?mt=8
Intressenter
Jorryt van Bommel Karlstads Universitet Beställare av applikationen. Arbetar med matematikdidaktik på Karlstads Universitet.
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.
