Utveckling av ett verktyg
Olof Stålnacke
Systemvetenskap, kandidat 2017
Luleå tekniska universitet Institutionen för system- och rymdteknik
Develop an IT artifact that provides formative feedback for students based on their programming assignments.
Background
One of the best methods to learn programming is by practice. Providing feedback to students is an important and a valuable factor for improving learning, which plays a vital part in the student’s possibility to enhance and improve its solutions.
Software development courses have several assignments and each course instructs about 100 students. To assess and provide feedback for all the students and each assignment demands considerable resources. In a survey conducted by TCO (2013) half of the respondents’ state that feedback is rarely or never given in reasonable time.
Method
Action Design Research (ADR) was used to intervene an organizational problem in parallel with building and evaluating an IT artifact.
Conclusion
The results from the study were four generated design principles and a proposed solution on how to use existing static code analysis tools for provide formative feedback to students.
Keywords: static code analysis, Automatic Grading Systems, formative feedback, assessment of programming assignments, educational programming aid, assess programming code, Action Design Research (ADR)
Syftet med studien är att utveckla ett verktyg för att ge formativ feedback till studenter i programmering.
Bakgrund
Att utföra praktiska programmeringsuppgifter är en bra metod för att lära sig programmera. Att förmedla feedback till studenter är både viktigt och värdefullt i undervisning med mål att förbättra inlärning. Inom programmering leder feedback till fördjupad förståelse för programmering och samtidigt ett underlag till att förbättra studenters lösningar.
Programmeringskurser innehåller ett stort antal studenter, och en kurs består av flertalet inlämningsuppgifter. Att bedöma dessa och lämna feedback till studenter för varje uppgift är tidskrävande. I en undersökning utförd av TCO (2013) anger hälften av de medverkande studenterna att feedback sällan eller aldrig ges inom rimlig tid.
Metod
I studien tillämpas forskningsmetoden Action Design Research (ADR) för att utreda ett organisatoriskt problem parallellt med att utveckla en IT-artefakt.
Slutsats
Studien resulterade i fyra stycken designprinciper genom framställandet av en IT-artefakt som genererar formativ feedback till studenter.
Nyckelord: statisk kodanalys, automatiska bedömningsverktyg, formativ feedback, bedömning av programmeringsuppgifter, hjälpmedel i programmeringsundervisning, bedöma programmeringskod, Action Design Research (ADR)
1 Inledning 2
1.1 Bakgrund 2
1.2 Problemdiskussion 2
1.3 Syfte 3
1.4 Forskningsfråga 4
1.5 Avgränsningar 4
1.6 Disposition 4
1.7 Definitioner 4
2 Teori 6
2.1 Feedback 6
2.2 Formativ feedback 6
2.3 Automatiska bedömningssystem 7
2.4 Java 7
2.5 Buildautomatisering 8
2.6 Mjukvarukvalitet 8
2.7 Testdriven utveckling 9
2.8 Programutvecklingsmetodik 10
Kanban 10
3 Metod 11
3.1 Forskningsmetod 11
3.2 Datainsamling 11
3.3 Sammanfattning av ADRprocessen 12
3.3.1 Fas 1 Problemformulering 12
3.3.2 Fas 2 Utveckling, intervention och utvärdering 12
3.3.3 Fas 3 Reflektion och lärdomar 13
3.3.4 Fas 4 Formalisering 13
4 Projektet 14
4.1 Medverkande organisation 14
4.2 ADR Första iteration 14
4.2.1 Problemformulering 14
4.2.2 Utveckling, intervention och utvärdering 15
4.2.3 Reflektion 17
4.3 ADR Andra iteration Val av analysverktyg 18
4.3.1 Problemformulering 18
4.4 ADR Tredje iteration 25
4.4.1 Problemformulering 25
4.4.2 Utveckling, intervention och utvärdering 26
4.4.3 Reflektion 27
4.5 ADR Fjärde iteration 28
4.5.1 Problemformulering 28
4.5.2 Utveckling, intervention och utvärdering 28
4.5.3 Reflektion 31
4.6 Tillämpade designprinciper 32
5 Diskussion och slutsats 34
5.2 Metoddiskussion 36
5.3 Fortsatt forskning 36
6. Referenser 37
Bilagor 39
Intervjuguide 39
Feedback från analysverktygen 42
1 Inledning
Det inledande kapitlet beskriver bakgrund om ämnet, problembeskrivning, syfte, forskningsfrågor, avgränsningar samt listar använda definitioner.
1.1 Bakgrund
Trots namnet automatiska bedömningssystems tidsenliga klang är konceptet att automatiskt utvärdera programkod ingen ny idé. Redan under 1960talet utvecklades ett program för att automatiskt kunna utvärdera studenters skrivna programkod (Hollingsworth, 1960). Genom att överlåta utvärderingen från lärare till maskin kunde lärarresurser frigöras till undervisning och fler elever kunde antas till utbildning. Det viktigaste av allt var att kunna leverera feedback omgående till elever menar Hollingsworth (1960).
Saikkonen, Malmi och Korhonen (2001) berättar i sin artikel hur studentantalet ökade under slutet av 1990talet vid programmeringskurser hos Tekniska högskolan i Helsingfors. Detta resulterade i att resurserna för rättning inte längre räckte till. De tidigare övningsuppgifterna som gavs ut på veckobasis med mål att hålla studenter aktiva under hela kursen uppfylldes inte längre med anledning av resursbristen och studenter fick därmed inte någon formativ feedback. Med anledning av detta utvecklades ett system för att bedöma studenters lösningar.
1.2 Problemdiskussion
Att vänta på feedback på uppgifter är inte ovanligt inom högre utbildning där lärare ofta har en hög arbetsbelastning. Universitetskurser i programmering kan innehålla uppemot hundra studenter och med ett flertal uppgifter. Att lämna feedback till vardera student och uppgift tar därmed mycket arbetstid vilket leder till att feedback blir försenad. Vid en enkätundersökning utförd av TCO (2013) anger hälften av studenterna att feedback sällan eller aldrig ges inom rimlig tid.
Praktiska övningarna är en av de bästa metoderna för att lära sig programmering uttrycker Demir, Soysal, Arslan, Yürekli & Yılmazel (2010), men samtidigt som antalet studenter vid kurstillfällen ökar så minskar denna typ av uppgifter berättar Ihantola, Ahoniemi, Karavirta & Seppälä (2010). Om programmeringskurser istället använder sig av ett automatiskt bedömningsverktyg behöver inte inlämningsuppgifter rationaliseras bort. Feedback är ett viktigt moment i programmeringskurser för att skapa en djupare förståelse för programmering.
Nuvarande bedömningssystem bedömer ofta programmeringsuppgifter utifrån enhetstester som utvärderar studentens utdata mot ett förväntat värde och ger därefter användaren en summativ bedömning med information om hur väl koden uppfyller det förväntade resultatet berättar AlaMutka (2005). Viss forskning visar hur det går med hjälp av mjukvarumetriker tillsammans med referenskod kan generera kvantitativ mätbara data för att använda som hjälpmedel när lärare återkopplar på studenters uppgifter (Koyya, P., Lee, Y., & Yang, J, 2013). Merparten av de system som nämns i tidigare forskning har aldrig blivit färdigkonstruerade eller tillgängliga för allmänheten.
Det finns flera tekniker för att utvärdera programmeringsuppgifter som skiljer varandra åt. En grundprincip för att kunna utvärdera ett program, i någon form, är att det måste finnas något godtyckligt värde att utvärdera mot fördefinierade krav eller referensmodell. Den mest förekommande teknik för att utvärdera programmeringsuppgifter i bedömningssystem är att testa programmets funktionalitet för att sedan jämföra programmets utdata. (AlaMutka, 2005)
I artikeln “Review of recent systems for automatic assessment of programming assignments” sammanfattar författarna att säkerheten i bedömningssystem måste förbättras och innehålla färre konfiguration. Detta är ett exempel på förbättringsåtgärd som kan hittas i den aktuella plattformen. En trend som syns i nyare system är integration med lärplattformar.
Nuvarande bedömningssystem inom programmering i utbildningskontext uppfyller inte behovet att lämna en pedagogisk formativ feedback som ett hjälpmedel för att studenten ska kunna utvecklas och förbättra sin kod. Flera av de nuvarande systemen koncentrerar sig på att lämna en summativ bedömning och det är få eller inga system som ger studenter en omgående nog uttrycklig formativ feedback på programmeringsuppgifter. Författaren AlaMutka (2005) berättar om hur analysverktyg kan användas för att kontrollera källkod, men hon har inte påträffat någon artikel som använder sig av dessa verktyg i utbildningsmiljö. Även Saikkonen, Malmi och Korhonen (2001) nämner i deras artikel “Fully Automatic Assessment of Programming Exercises” att ett tillägg för att bedöma kodstil skulle vara ett användbart hjälpmedel, men är inget som de implementerat. Med nämnd anledning är denna studies ansats att utveckla ett verktyg som ger formativ feedback till studenter genom att tillämpa analysverktyg.
1.3 Syfte
Syftet med studien är att utveckla ett verktyg som ger formativ feedback till studenter i programmering samt att generera designprinciper.
1.4 Forskningsfråga
Hur kan ett analysverktyg utvecklas för att ge formativ feedback till studenter?
1.5 Avgränsningar
Studien avgränsas till att verifiera programkod genom att använda existerande statiska kodanalysverktyg för Java tillsammans med enhetstest i en automatiserad process som utförs av ett buildverktyg. De statiska analyserade egenskaperna är begränsade till kodstil, koddesign, död kod och buggdetektering.
1.6 Disposition
Studien fortsätter med att först presentera relevant teori för forskningsfråga för att sedan redovisa metodval med sammanfattning av studiens metodtillämpning. Vidare presenteras projektet, strukturerad efter vald metod och genom forskningsmetoden genererar designprinciper som diskuteras i diskussion och slutsatser. Vidare redovisas källförteckning samt bilagor bestående av rådata i form av kod och svar från intervjuobjekt medverkande i enkätundersökning.
1.7 Definitioner
Tabell 1 Definitioner
Benämning Definition
ADR Action Design Research,
forskningsmetod
Buildverktyg Används för att automatisera aktiviteter, såsom enhetstest och kompilering, inom system och mjukvaruutveckling
Död kod Kod som exekveras när ett dataprogram körs, men koden används aldrig för uträkning. (Koden används inte) Formativ feedback Information med syfte att förändra
arbetssätt och förbättra inlärning.
IDE Utvecklingsmiljö (Integrated
Development Environment)
Kodduplikation Term som innebär att en sekvens av källkoden förekommer mer än en gång Kodstil En uppsättning av regler som används
för hur källkod inom
mjukvaruutveckling bör skrivas
LTU Luleå tekniska universitet
Mjukvarubugg Programvarufel som orsakas av oväntat eller inkorrekt resultat som kan leda till att program kraschar
Open Source Öppen källkod, programvara som är tillgänglig för att användas och anpassas Refaktorera En teknik där kod omstruktureras för att
förenkla vidareutveckling samt förbättra läsbarhet och underhållsmässighet Testdriven utveckling Utvecklingsmetod där test av kod är det
centrala och avgörande
2 Teori
2.1 Feedback
I bedömningsprocessen är feedback en avgörande faktor för att förbättra kunskaper och anskaffa nya färdigheter (Shute, 2007). Feedback går att kategorisera efter egenskap, såsom formativ och summativ. Feedback definieras som att informera studenten om dennes resultat (Sadler, 1989). Shute (2007) menar att feedback är en viktig motivationsfaktor gällande studier.
2.2 Formativ feedback
Författaren Shute (2007) definierar i sin litteraturstudie formativ feedback som den information som ges till den studerande med syfte att förändra dennes sätt att tänka eller agera med mål att förbättra inlärning. Vidare beskriver Shute att formativ feedback, oavsett om det kommer från en dator eller lärare, är till för att förstärka inlärningen och förbättra processen. Utöver inflytande på prestation beskriver författaren feedback som en viktig beståndsdel för att motivera lärandet. Shute menar att formativ feedback som ges till studenter på rätt sätt kan förbättra inlärningen väsentligt. Feedback som information kan ges ur två aspekter; att studenten får reda på rätt svar samt vägledning om hur målet ska uppnås. Vidare uttrycker Shute att någonting som är viktigt med formativ feedback är att resultat och prestation kontinuerligt förbättras.
Författaren Sadler (1989) beskriver hur feedback i formativ bedömning används för att studenter skall kunna självreglera sitt lärande. Han visar på tre faktorer som är centrala för effektiviteten i den bedömningen:
● Hjälpa studenten att identifiera vad det önskade målet består av
● Ge studenten information om hur väl dennes lösning matchar mot uppsatt mål
● Förklara hur gapet kan minskas mellan studentens lösning och uppsatt mål
Sadler (1989) menar att en grundläggande idé om formativ bedömning är att studenten måste vara medveten om att det finns förbättringar att utföra. Sadler förklarar att om studenten ska kunna bilda en medvetenhet måste denne förbättra sin förmåga att överblicka kvaliteten av sitt egna arbete under arbetets gång. Först då kan studentens kompetens förbättras samtidigt som "trial and error"metoden, som slumpmässigt löser
Locke & Latham (1990) menar att om gapet går att minska mellan studentens lösning och ett uppsatt mål kan det motivera till förbättrad prestation, vilket även minskar osäkerheten om hur väl studenten har presterat med sin lösning.
2.3 Automatiska bedömningssystem
System för att automatiskt utvärdera studenters programmeringskod har utvecklats sedan 1960talet (Hollingsworth). Sedan dess har flertalet system med varierande analyserande egenskaper för bedömning utvecklats (AlaMutka 2005). Vidare menar AlaMutka att trots skillnader i systemens egenskaper finns en gemensam grundprincip – det måste finnas ett uttryckligt värde att analysera.
De tester som används i bedömningssystem kan kategoriseras till två grupper, statiska och dynamiska. Dynamiska tester är när dynamiken i kodens beteende testas, författaren Patton (2013) menar att dynamiska tester är vad som normalt förknippas med test – tester körs för att prova mjukvaran. Dynamiska testtekniker används för att mäta effektivitet och funktionalitet. Ett tekniskt krav för att dynamiskt kunna analysera programkod är en korrekt skriven syntax (AlaMutka 2005). I dagens utvecklingsmiljöer varnas oftast användaren om syntaxen inte är korrekt redan innan programmet kompileras eller exekveras. Vidare menar AlaMutka att en korrekt syntax inte per automatik resulterar i en god kodstil.
Att utföra statisk kodanalys för att exempelvis bedöma kodstil behöver inte, till skillnad från dynamiska testerna, de statiska teknikerna exekveras för att kunna analyseras. Några andra exempel på statiska testtekniker är design, hitta potentiella buggar, hitta död kod och mjukvarumetriker. Flertalet av de bedömningssystem som nämns i forskning använder sig av både statiska och dynamiska tester. (Ihantola et al., 2010)
För att sammanfatta skillnaden mellan tester gör Patton (2013) en parallell mellan testtyper som när en begagnad bil undersöks. Att sparka på däcken, kolla in lacken och inspektera i motorutrymmet är exempel på statisk testning. Medan att starta bilen, lyssna på motorljudet och ta ut bilen för en provtur är exempel på dynamisk testning.
2.4 Java
Java är ett objektorienterat programspråk som är utvecklat av Sun Microsystems. År 1995 presenterades språket för första gången ("What is Java and why do I need it?", 2017). Språket är ett av de mest förekommande som används i dag, en bidragande orsak är att Java är plattformsoberoende (Deitel & Deitel, 2012).
2.5 Buildautomatisering
Skribenten Enos (2013) berättar att om det är något mjukvaruutvecklare är bra på är det att automatisera saker som tidigare har utförts manuellt och därmed göra livet enklare för människor. Buildautomatisering är processen som hanterar och organiserar skapandet av mjukvaruartefakter. Enos menar att med hjälp av automatisering behöver inte de tidigare monotona och repeterbara uppgifterna utföras manuellt. Vidare berättar Enos att några moment som kan ingå i buildprocessen är; kompilera källkod, köra automatiserade tester och distribuera kod. Genom automatisering effektiviseras uppgifterna genom att de utförs fortare och blir mer konsekventa genom att processen använder fördefinierade instruktioner för hur automatiseringen skall gå till (Agile Alliance, n.d.).
2.6 Mjukvarukvalitet
Mjukvarukvalitet går att begrunda på olika sätt. Spinellis (2006) menar att det kan ses på två sätt; hur väl fastställda krav uppfylls samt från en individs perspektiv, exempelvis hur väl kvaliteten uppfyller kunden eller användarens förväntningar och behov. Tillsammans med tid och kostnad är kvalitet ett centralt begrepp för hur väl ett projekt lyckas. Vidare berättar Spinellis om hur kvalitet är det enda av de tre centrala begreppen som faktiskt inte projektledare kan styra över till skillnad från tid och kostnad. I samma stycke gör författaren en liknelse för att visa vilken effekt bristande kvalitet kan få genom att beskriva hur en rymdsond kan bli till skrot efter att en misskalkylering på en variabel har skett i mjukvaran och där den ödesdigra konsekvensen inte går att förändra då det redan är för sent.
Läsbarhet Att upprätthålla en god kodkvalitet
Läsbarhet är en kvalitetsegenskap som påverkar mjukvarans underhållsmässighet. Att följa uppsatta riktlinjer för hur programkod bör skrivas förbättrar läsbarheten (Caron, 2000, Spinellis 2006) och gör kod mer lättförståelig (Oracle.com, 1999). Att upprätthålla en strukturerad och konsekvent kodstil uppnås genom att följa en kodkonvention. Denna typ av konvention består av en uppsättning riktlinjer och regler i hur programmeringsstil, rutiner och metoder bör utformas. Vidare menar Spinellis att en kodstil kan vara konsekvent på två sätt, internt eller externt. Med internt menas att kodstilen som tillämpas i en modul ska följas och tillämpas i andra moduler för projektet. På detta sätt kan tid sparas genom att flera kodstilar inte behöver tolkas.
Med extern konsekvens syftar Spinellis på att kodstilen ska vara etablerad. Genom att använda samma kodstil upprepade gånger är det möjligt att använda erfarenhet från tidigare projekt till nya och därmed utveckla ett kodstilsmönster.
Mjukvarumetrik
Antal rader av källkod eller benämningen SLOC (Source Lines of Code) är en välkänd metrik som används frekvent inom mjukvaruutveckling. Metriken används som indata för att kunna konstruera modeller för att uppskatta projektkostnader. Funktionaliteten hos metriken är att räkna antalet kodrader källkod och vanligtvis bortse från kommenterade rader. Det finns olika tekniker för att räkna kodrader. De två vanligaste mätmetoderna benämns fysisk mätning och logisk mätning. De största skiljaktigheterna är att den fysiska mätningen mäter antal fysiska kodrader, medan den logiska mätningen mäter antalet kontrollstrukturer i koden. (Nguyen, DeedsRubin, Tan & Boehm, 2007)
2.7 Testdriven utveckling
Testdriven utveckling är en systemutvecklingsmetod som utgår från att skriva tester före utvecklingskod skrivs, Beck (2011) beskriver hur tillämpningen lägger mer fokus på att uppfylla definierade krav än på att skriva tester som ska godkänna redan skriven kod, vilket ofta leder till extraarbete. Vidare berättar Beck hur metodens process fortlöper så länge det tillkommer ny utvecklingskod.
Testdriven utvecklingscykel (Beck, 2011).
1. Skriv ett test
Enligt författaren är en viktig grundregel att alltid börja med att skriva ett misslyckande test innan någon utvecklingskod skrivs över huvud taget. Konceptet går ut på att skriva flera tester istället för ett stort för att visa på att sekventiella framsteg sker.
2. Kontrollera att testet misslyckas
För att försäkra sig om att testet är rätt konstruerat exekveras testet före någon programkod är skriven. Detta görs för att försäkra sig om att testet inte passeras innan ny funktionalitet är implementerad. Om testet godkänns är testet felkonstruerat. På detta sätt går att försäkra sig mot kodduplicering, det vill säga att den tänkta funktionaliteten redan existerar.
3. Skriv koden
Detta steg går ut på att skriva programkod som passerar testet. Koden behöver inte vara perfekt, vid ett senare tillfälle kommer koden att refaktoreras.
4. Kontrollera att testkod passerar
Nu körs testerna igen för att försäkra sig om att den nya skrivna koden passerar testerna som tänkt. Vidare kontrolleras även att de tidigare testerna fortfarande passeras, det vill säga, att den nya implementerade koden inte påverkar och
orsakar problem med tidigare funktionalitet.
5. Refaktorera kod
Sista steget är att refaktorera. Detta görs för att förenkla och städa kod för att uppnå en god kodkvalitet gällande läsbarhet samt underhållsmässighet.
2.8 Programutvecklingsmetodik
Kanban
Kanban är en metodisk strategi som har tillämpats över ett halvt sekel inom tillverkningsindustrin i Japan och börjades att användas inom mjukvaruutveckling av ett ITteam vid Microsoft år 2004. Metoden kännetecknas av ett antal koncept, först och främst av att flöden visualiseras genom användning av tavlor där arbetet delas upp i mindre beståndsdelar där varje uppgift skrivs ett kort som sätts upp på en tavla. Ett annat centralt begrepp för verktyget är att begränsa pågående arbeten, WIP (Work In Progress), genom att uttryckligen begränsa antalet arbetsuppgifter som pågår parallellt.
En tredje funktion som kännetecknas av strategin är att mäta ledtid, det vill säga hur lång tid en arbetsuppgift tar att slutföra. Detta är ett steg i att effektivisera ledtider genom att dels minska ledtider men samtidigt bli bättre på att uppskatta dessa.
(Ahmad, Markkula and Oivo, 2013)
3 Metod
I detta kapitel presenteras valet av forskningsmetod med tillhörande motivering.
Därefter presenteras hur metodens moment tillämpades under studien.
3.1 Forskningsmetod
I introduktionskapitlet nämns att syftet med studien är att utveckla ett verktyg som ger formativ feedback till studenter i programmering samt att generera designprinciper
För denna studie valdes forskningsmetoden Action Design Research, vidare benämnd ADR. Metoden kombinerar de två forskningsmetoderna AR (Action Research) och DSR (Design Science Research) och lämpar sig för att utreda ett organisatoriskt problem och parallellt utveckla en ITartefakt i den kontextuella miljön, programmeringskurs i Java vid Luleå tekniska universitet.
3.2 Datainsamling
Tabell 2 Datainsamling
Intressent Område Datainsamlingsmetod Iteration
Problemägare Problemformulering, Utveckling,
Intervention
Ostrukturerade intervjuer / Brainstorming
1, 2, 3, 4
Lärare Utvärdering Ostrukturerade intervjuer 3
Student Utvärdering (slutanvändare)
Semistrukturerade intervjuer 4
Under utvärdering med studenter utfördes intervjuer (se bilaga). Semistrukturerade intervjuer användes för att ge respondenterna friheten att uttrycka sig och samtidigt hålla intervjun inom det relevanta ämnet. Utvärderingar utfördes genom att intervjuare och respondent möttes och applikationen testades medan intervjun spelades in och i efterhand transkriberades. Samtidigt som utvärderingen ägde rum observerades applikationen på studentens monitor. Efter att alla intervjuerna var genomförda bearbetades intervjudata genom att sammanfattas under den fjärde iterationen i stycket Utvärdering av applikation med slutanvändare .
3.3 Sammanfattning av ADRprocessen
I detta stycke redovisas ADRprocessens fyra faser samt tillämpningen av dessa under projektets gång. Metodens faser består av 1. Problemformulering, 2. Utveckling, intervention, utvärdering, 3. Reflektion samt 4. Formalisering. Varje fas består av ett antal uppsatta uppgifter och principer. Forskningsprocessens faser problemformulering, utveckling, intervention & utvärdering samt reflektion itererades under projektets längd.
3.3.1 Fas 1 Problemformulering
Det första momentet i den initiala fasen karaktäriseras av problemidentifiering och problemformulering. När dessa två element är identifierade är nästa steg att granska tidigare forskning för att identifiera vad som redan är utfört inom problemområdet.
Detta är nödvändigt för att veta vilka möjligheter som finns samt för att veta vad som inte är utforskat inom ämnet. Detta moment är en förstudie för den tänkta forskningsfrågan. (Sein, Henfridsson, Purao, Rossi & Lindgren, 2011)
Sein et al. (2011) menar att ett kritiskt och väsentligt element under denna fas är att tidigt upprätthålla ett åtagande med medverkande organisation som ska bestå under hela studiens hela gång.
Uppgifter tillhörande problemformuleringsfasen. (Sein et al., 2011) 1. Identifiera och konceptualisera möjligheterna med forskningen.
2. Formulera initiala forskningsfrågor
3. Utmåla problemet som en instans av en grupp av problem
4. Identifiera bidragande teoretiska grunder och tidigare tekniska framsteg 5. Upprätthålla ett långsiktigt åtagande med medverkande organisation 6. Sätt upp roller och skyldigheter
3.3.2 Fas 2 Utveckling, intervention och utvärdering
Andra fasen bygger vidare på problemet och dess omgivning som definierades under den inledande fasen. Detta är en förutsättning för att kunna skapa samt utforma en initial design för en ITartefakt som sedan ligger till grund för kommande iterationer och utformning genom organisatoriskt användande samt designutveckling genom ett iterativt arbetssätt. Denna fas knyter ihop utveckling, intervention och utvärdering.
(Sein et al., 2011)
3.3.3 Fas 3 Reflektion och lärdomar
Tredje fasen flyttar fokus från att lösa ett organisatoriskt problem genom att designa en ITartefakt till att visa hur forskningsprocessen även består av medveten reflektion över hur problemet inramas. (Sein et al., 2011)
3.3.4 Fas 4 Formalisering
Under den sista fasen av metoden lyfts problemet och lösningen för att kunna generaliseras. Fasen ska resultera och framställa generaliserade designprinciper som bidrag till forskning. (Sein et al., 2011)
4 Projektet
Detta kapitel presenterar utveckling, undersökning och utvärdering av projektet. Först presenteras medverkande organisation därefter initieras projektet genom att tillämpa ADR första fas problemformulering. Vidare följer ADR faser 2. Utveckling, intervention & utvärdering och slutligen 3. Reflektion. Dessa faser, tillsammans med första fasen, itereras under projektets gång. Avslutningsvis, efter att alla iterationer är genomförda utmynnar slutsatser i den fjärde fasen — Formalisering.
4.1 Medverkande organisation
Luleå tekniska universitet
Medverkande organisation är LTU (Luleå tekniska universitet), som är Skandinaviens nordligaste tekniska universitet. Universitet har omkring 15 000 studenter och 1700 anställda med en omsättning på totalt 1,6 miljarder kronor per år. Utöver utbildning bedrivs forskning med samarbete med ett flertal svenska globala företag.
(https://www.ltu.se/ltu/Organisation, 2017)
Vid institutionen för system och rymdteknik hålls två kurser i Javaprogrammering, Den första kursen innehållet moment som problemlösning, strukturering, beräkning, jämförelser, selektion, iteration, enkla algoritmer med fler. Fortsättningskursen introducerar hantering av klasser och objekt, konstruktion av grafiska gränssnitt, metoder, arv, abstrakta klasser, interface och databaskoppling.
4.2 ADR Första iteration
4.2.1 Problemformulering
När studien initierades med problemägaren inleddes första ADRfasen, problemformulering. Under denna fas formades den grundläggande problemformulering kring automatiserade bedömningstillämpningar i ADRteamet.
Den kretsade kring hur det var möjligt att använda och anpassa dessa för att kunna uppfylla målen med de olika bedömningskriterierna av uppgifter i programmeringskurs.
Upplevda problem
Det centrala problemet som identifierades under den första fasen var att nuvarande rättningsprocess är alltför resurskrävande för att kunna leverera feedback till studenter
I programmeringskurserna vid institutionen rättas uppgifterna manuellt av lärarna genom att de visuellt granskar uppgifterna. Tillvägagångssättet för rättning är att uppgifter bedöms efter regler och riktlinjer inom objektorienterad programmering som bland annat koddesign och designmönster för att bedöma hur väl studenter tillämpar olika programmeringskoncept. Kurserna har omkring 100 deltagare och respektive kurs har 4–6 inlämningsuppgifter. Att bedöma studenter och lämna feedback inom godtycklig tid är en ohållbar situation och väldigt resurskrävande. Detta är ett generellt problem vid svenska högskolor vilket bekräftats av en enkätundersökning utförd av TCO år 2013.
Att förändra bedömningsprocessen genom automatisering är ett tillvägagångssätt som har blivit en standardiserat metod vid MOOCS (Massive Open Online Courses).
Denna typ av automatisering använder sig ofta av enhetstester för att utvärdera och jämföra studenters program.
Tabell 3 Problem med nuvarande tillämpning
Problem Nuvarande bedömningssätt
Studenter får inte feedback levererad inom
skälig Ϥd. Resurs‐ och Ϥdskrävande
Studenter moϤveras inte Ϥll aϤ utvecklas,
exempelvis genom förbäϤrad lösning Feedback når studenten för sent
Lärarens bedömning Bedömning sker manuellt
4.2.2 Utveckling, intervention och utvärdering
Med den initiala problemformulering som grundunderlag utforskades existerande bedömningsverktyg. Majoriteten av de bedömningsverktyg som undersöktes fokuserade på test av inputoutput data, vilket i sig inte är tillräckligt för organisationen för att kunna leverera en användbar feedback till studenter.
ADRteamet bestämde sig för att gå vidare med att utveckla en prototyp för att på ett automatiserat sätt kunna utvärdera studenters programkod och leverera feedback.
Detta för att motivera studenter till att förbättra sina lösningsförslag och programmeringskunskaper för att uppnå kursmål.
Kravinsamling
Tillsammans med problemägaren diskuterades vilken typ av funktionalitet som var önskvärd för artefakten. Under brainstormingsessioner identifierade ADRteamet flertalet potentiella statiska analysmönster som ITartefakten bör använda sig av för att förmedla feedback till slutanvändare. Dessa egenskaper utformades till krav i
kravspecifikation. Kraven kategoriserades efter funktionella och ickefunktionella krav.
Tabell 4 Funktionella krav Krav ID Kravdefinition FK 1.0
‐ 1.1
‐ 1.2
‐ 1.3
‐ 1.4
Systemet skall analysera studentens kodsϤl Kontrollera indentering av kod
Kontrollera namngivning på variabler, metoder med fler.
Kontrollera aϤ kod är kommenterad Kontrollera konvenϤon för hakparentes
FK 2 Systemet skall kontrollera om studentens svar är korrekt
FK 3 Systemet skall kunna begränsa lösningsförslag Ϥll specificerat antal kodrader FK 4 Systemet skall analysera antalet använda java‐nyckelord
FK 5
‐ 5.1
‐ 5.2
Systemet skall kunna generera feedback Ϥll studenten Feedbacken som systemet genererar skall kunna spelifieras Systemet skall kunna presentera resultat som en highscore lista FK7.0
‐ 7.1 Systemet skall ge studenten förslag på kodopϤmering och idenϤfiera buggar Leta eϤer död kod
FK 8 IdenϤfiera kodduplicering
Tabell 5 Icke funktionella krav
Egenskap Beskrivning
Användarvänligt Det ska gå snabbt för studenter aϤ säϤa sig in i systemet.
Användare ska kunna använda sig av valfri IDE / texteditor.
Användare ska inte behöva uϤöra konfiguraϤon Anpassningsbar
het Systemet ska vara anpassningsbart genom aϤ vara modulärt Underhållbarhet Det ska vara enkelt konstruera fler programmeringsuppgiϤer.
Systemet ska vara läϤ aϤ administrera och konfigurera analysegenskaper.
Snabbhet Systemet skall lämna feedback Ϥll student omgående FunkϤonalitet Feedback skall moϤvera studenten Ϥll en förbäϤrad lösning
Under den initiala sessionen drogs slutsatsen att fler mindre uppgifter bör konstrueras istället för stora uppgifter, ett steg för att minska komplexiteten och successivt göra små sekventiella framsteg för att motivera studenten.
4.2.3 Reflektion
Efter initialt försök att ta fram grundfunktionalitet för systemet blev det uppenbart att projekttid till förfogande ej var tillräckligt för att kunna konstruera flertalet av den önskade funktionaliteten för systemet. Det var därmed en nödvändighet att begränsa projektet. Istället för att skriva egen programkod för önskad funktionalitet föreslogs att istället använda sig av existerande statiska Open Source analysverktyg. Detta godkändes av problemägare.
Det förändrade arbetssättet innebär både fördelar och nackdelar. En nackdel är att projektet tvingas anpassas efter marknadens tillgängliga analysverktyg vilket leder till att vissa krav och funktionalitet kommer att få prioriteras bort. En fördel är att dessa verktyg är väl testade inom mjukvaruutveckling och dess industri. En annan fördel är att verktygen är skrivna av flertalet utvecklare med lång erfarenhet och kunskap inom ämnet, vilket leder till både säkrare och pålitligare programvara jämförelsevis mot att konstruera funktionaliteten själv. En tredje fördel syftar till återanvändning, att inte uppfinna hjulet på nytt.
Samtidigt som projektet anpassades efter de tillgängliga verktygen var det viktigt att det centrala i studien, att motivera studenten med förbättringsförslag genom att ge formativ feedback, inte skulle påverkas mer än nödvändigt. Vidare kommer tillgängliga Open Source analysverktyg inom Java att utforskas där dessa kommer att prioriteras och väljas efter vilka som ger information i form av formativ feedback om hur kod kan förbättras. Detta för att motivera studenten till att minska gapet mellan studentens lösning och en förfinad lösning.
Tabell 6 Bortprioriterade analysegenskaper
Egenskap Beskrivning
Analysera antalet nyckelord (Java Keyword) Genom aϤ analysera vilka nyckelord student använder för specifik uppgiϤ kan eventuellt förbäϤringsförslag föreslås.
Poängsystem för uppgiϤer Bedöma studenten eϤer hur väl lösning passar mot exempelvis referensmodell.
Spelifieriad feedback Öka slutanvändares engagemang genom aϤ använda olika spelmekanismer som
exempelvis nivå, experience, märken med fler.
Ovanstående krav har blivit bortprioriterade då dessa anses vara för tidskrävande och komplexa att utveckla. Genom att bortse från dessa krav ges mer tid till att hinna färdigställa en fungerande prototyp för kvarstående krav.
Tabell 7 Preliminära designprinciper
Preliminära designprinciper Källa
Vara generaliserbar Analysegenskaper bör inte konfigureras
uppgiftspecifikt, utan istället generaliseras till programmeringskurs innehåll och nivå. Det underlättar och förenklar processen att skapa nya övningsuppgifter.
Identifierad i projekt
Skapa medvetenhet Använd feedback för att skapa medvetenhet hos studenten om hur lösningsförslag kan förbättras
Shute (2007)
Vara motiverande Feedback skall motivera studenten till att förbättra sin prestation
Locke & Latham (1990)
4.3 ADR Andra iteration Val av analysverktyg
4.3.1 Problemformulering
Under denna fas utvecklades problemet och blev betraktat från ett annat perspektiv.
Från att inledningsvis ha fokuserat på den organisatoriska kontexten fick problemet en förändrad form till att undersöka hur en ITartefakt kan utvecklas där analysverktyg för Java används för att automatisera feedbackprocessen.
Upplevda problem
Hur skall existerande analysverktyg användas i utbildningsmiljö för att ge studenter formativ feedback? Vilka verktyg skall användas?
4.3.2 Utveckling, intervention och utvärdering
Val av analysverktyg
Under utvärdering i föregående iteration togs beslutet tillsammans med problemägaren att bortprioritera egenutvecklad programkod till förmån att nyttja befintliga Open Source analysverktyg. Genom att utforska vilka aktuella analysverktyg som fanns till förfogande för Javaprogrammering valdes tre verktyg ut för att ingå i projektet.
Samtliga verktyg är väl etablerade inom Javautveckling. Verktygen valdes ut efter förmågan att generera förbättringsförslag på studenters lösningar samt matchades mot de krav som tidigare fastställdes i kravspecifikationen.
Analysverktyg Checkstyle
Checkstyle var det första utvecklingsverktyget som valdes för att kunna observera hur studenten efterlever specificerad kodstil. Verktyget kontrollerar automatiskt Javakod och verifierar namngivningskonvention, användning av hakparenteser, “white space”formatering, användning av import med många fler kodstilsegenskaper.
Checkstyle är användbart för att kontrollera att koden är skriven efter riktlinjer.
Programmet innehåller möjlighet att själv konfigurera, ändra regler eller tillämpa kodkonventioner inom Java från exempelvis Sun och Google.
AlaMutka (2005) nämner i sin artikel att verktyget Checkstyle kan användas för att kontrollera studentens kodstil, hon har dock inte kunnat hitta någon artikel som använder verktyget i utbildningsmiljö. Saikkonen, Malmi och Korhonen (2001) nämner att ett tillägg för att bedöma kodstil skulle vara ett användbart hjälpmedel, men är inget som dem själva har implementerat.
Figur 1 Checkstyle rapport
:compileJava
:processResources UP‐TO‐DATE :classes
:checkstyleMain [ant:checkstyle]
/home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:3:5: warning:
'{' should be on the previous line.
[ant:checkstyle]
/home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:4: warning:
'method def' child have incorrect indentation level 9, expected level should be 8.
[ant:checkstyle]
/home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:8:5: warning:
'{' should be on the previous line.
[ant:checkstyle]
/home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:13:5:
warning: '{' should be on the previous line.
[ant:checkstyle]
/home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:17:42:
warning: WhitespaceAround: '{' is not preceded with whitespace.
BUILD SUCCESSFUL
Total time: 1.498 secs
I figuren visas ett exempel på Checkstyle i användning. Verktyget körs i kommandoprompten där feedback skrivs ut i egenskap av kodvarningar innehållandes vilken rad fel finns och vad den koden bör ersättas med.
Analysverktyget PMD
Checkstyles användningsområde är begränsat och riktar sig mot att bedöma kodstil och räcker därför inte för att uppfylla problemägarens krav. Med den anledning kompletteras artefakten av analysverktyget PMD för att kunna kontrollera mer komplicerade regler såsom programmets design, död kod, överansträngd kod, optimerbar kod och onödiga kodduplikationer. PMD genererar feedback genom rapporter i XML eller HTMLformat.
Figur 2 PMD rapport
olof@olof‐VirtualBox:~/exjobb/Calculator$ gradle pmdMain :pmdMain
2 PMD rule violations were found. See the report at:
file:///home/olof/exjobb/Calculator/build/reports/pmd/main.html
BUILD SUCCESSFUL
Total time: 1.495 secs
Analysverktyget FindBugs
FindBugs är ett verktyg som används för att hitta buggar. FindBugs klassificerar buggar i kategorier beroende på allvarlighetsgrad på exempelvis dålig praxis, korrekthet, prestanda samt efter kod som har invecklad konstruktion. Till skillnad från Checkstyle och PMD analyseras Java bytecode. Därmed kan andra typer av buggar hittas än vad verktyget PMD gör, för den skull kompletterar verktygen varandra.
Figur 3 Findbugs rapport
olof@olof‐VirtualBox:~/exjobb/Calculator$ gradle check :compileJava UP‐TO‐DATE
:processResources UP‐TO‐DATE
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':findbugsMain'.
> FindBugs rule violations were found. See the report at:
file:///home/olof/exjobb/Calculator/build/reports/findbugs/main. html
* Try:
Run with ‐‐stacktrace option to get the stack trace. Run with ‐‐info or
‐‐debug option to get more log output.
BUILD FAILED
Total time: 3.327 secs
Testdriven utveckling
Utöver att verifiera och analysera användarnas källkod var ett prioriterat funktionalitetskrav att kunna kontrollera om studentens svar är korrekt. Att använda sig av enhetstest för att kontrollera studentens output är ett användbart sätt.
Figur 4 Testklass för MyCalculator
import static org . junit . Assert .*;
import java . io . FileNotFoundException;
import java . io . IOException;
import org . junit . Ignore;
import org . junit . Test;
public class MyCalculatorTest {
@Test
public void testAdd (){
MyCalculator calc = new MyCalculator (); // MyCalculator is tested assertEquals ( 20 , calc . add ( 10 , 10 ));
}
@Test
public void testSubtract (){
MyCalculator calc = new MyCalculator (); // MyCalculator is tested assertEquals ( 0 , calc . subtract ( 10 , 10 ));
}
@Test
public void testMultiply (){
MyCalculator calc = new MyCalculator (); // MyCalculator is tested assertEquals ( 369 , calc . multiply ( 123 , 3 ));
}
@Test
public void testDivide () {
MyCalculator calc = new MyCalculator (); // MyCalculator is tested assertEquals ( 41 , calc . divide ( 123 , 3 ));
}
Under iterationen konstruerades tester för övningsuppgifter. Källkoden ovan är testklassen för MyCalculator som innehåller 4 stycken test där addition, subtraktion, multiplikation samt division testas. För samtliga metoder skickas två inparametrar in som ska använda under sin specifika metod och returnera ett värde.
Figur 5 Lösningsklassen MyCalculator
public class MyCalculator {
public int add ( int num1 , int num2 ) { return num1 + num2;
}
public int subtract ( int num1 , int num2 ) { return num1 ‐ num2;
}
public int multiply ( int num1 , int num2 ) { return num1 * num2;
}
public int divide ( int num1 , int num2 ) { return num1 / num2;
} }
Ovan visas ett exempel på hur tänkta slutanvändare av systemet har konstruerat ett lösningsförslag med metodnamn som överensstämmer mot testklassen. Detta test skall sedan passera de tidigare konstruerade testerna.
Figur 6 Enhetstest exekveras
Här visas hur enhetstestet för lösningsklassen MyCalculator körs. Skärmdumpen visar hur de fyra testmetoderna; addition, subtraktion, division samt multiplikation kontrolleras. Varje test passeras, vilket indikeras av den gröna texten “PASSED” till höger om testmetodens namn.
Tabell 8 Statiska analysverktyg för Java
Verktyg Licens Webbplats
Checkstyle GNU LGPL V2.1 hϤp://checkstyle.sourceforge.net
PMD BSD‐licens hϤp://pmd.github.io
FindBugs GNU LGPL hϤp://findbugs.sourceforge.net
För att täcka upp de analyserande kraven i kravspecifikationen, bortsett från de tidigare bortprioriterade egenskaperna, användes tre analysverktyg. I nedanstående tabell matchas verktygen mot de krav som hanteras.
Tabell 9 Kravmatchning
Analyserande krav Checkstyle PMD Findbugs TDD
1.1 ‐ Indentering av kod x
1.2 ‐ NamndeklaraϤoner x x
1.3 ‐ Kodkommentering x
1.4 ‐ Användning av
hakparentes x x
2.0 ‐ Kontrollera räϤ svar x
3.0 ‐ Begränsa antal kodrader x
5.0 ‐ Ge feedback x x x x
7.0 ‐ OpϤmeringsförslag
(prestanda) x x
7.1 ‐ Leta eϤer död kod x
8.0 ‐ IdenϤfiera kodduplicering x
Val av buildverktyg
För att på ett automatiserat sätt kunna inkludera både kompilering av programkod, enhetstest och exekvering av analysverktyg tillämpades ett buildverktyg vid namn Gradle. Genom att konstruera en buildkonfiguration där analysverktygen definieras att användas och regeluppsättningar konfigureras behöver inte användarna själva utföra någon installation eller installera analysverktyg. Detta hanteras av buildverktyget.
Tabell 10 Val av verktyg
Motiveringar till val av buildverktyg
Erfarenhet Kännedom om verktyget fanns sedan tidigare Anpassningsbarhet Verktyget är enkelt att konfigurera
Användarvänlighet Enkelt för slutanvändare att använda Tillgänglighet Finns för Windows, Linux och Mac OS
4.3.3 Reflektion
Kraven som noteras från kravspecifikationen kunde täckas upp genom att tillämpa analysverktyg tillsammans med enhetstest. Vidare kunde analysprocessen effektiviseras genom att nyttja buildverktyg där allt är konfigurerat på förhand och sköts automatiskt vilket uppfyller det icke funktionella kraven Användare ska inte behöva utföra konfiguration och kravet Systemet skall lämna feedback till student omgående .
För nästa iteration måste formatering över feedback ses över. I regelverken för analysverktygen Checkstyle och PMD måste regler definieras bättre. Vidare måste feedbacken som visas för slutanvändare vara mer enhetlig och samstämmig.
Tabell 11 Fasens tillämpade designprinciper
Preliminära designprinciper Källa
Vara
överskådlig
När studenten testar sin lösning bör varningar presenteras direkt istället för att bli hänvisade till en htmlrapport. Användare ska uppmärksammas av varningarna direkt för att omgående börja utreda hur felaktigheter ska lösas
Identifierad i projekt
Skapa god struktur
Att arbeta med ett test i taget för att tillämpa ett sekventiellt arbetssätt
Beck (2011) Ge
omgående feedback
Feedback skall ges omgående när lösningen är som mest aktuell
Konceptet Automatise rad
bedömning Ge
feedback efter försök
Feedback bör ges till användare efter att ett lösningsförslag har utförts
Shute (2007)
4.4 ADR Tredje iteration
Innehållet i den tredje iteration fokuserar främst på att förbättra strukturen för resultatet som visas i samband med att användarens övningsuppgift kontrolleras.
Vidare behövs flera regler justeras, främst gällande kodstil, men även anpassa regler till nivå för introduktionskurs i programmering före ITartefakten testas av slutanvändare.
4.4.1 Problemformulering
Under tredje iterationen förflyttades problemet till detaljnivå och blev samtidigt nedbrutet till mindre beståndsdelar.
Under tidigare iteration har det reflekterats över att feedback som genererades av verktygen inte var enhetlig. En fråga som uppstod var hur feedback skulle kunna genereras enhetligt för att användaren inte ska behöva klicka sig fram för att läsa flera feedbackrapporter. En annan fråga som uppkom var hur strikta kodstilsregler bör vara
och hur ADRteamet gå tillväga gällande anpassning av regler för att hålla en lämplig nivå i förhållande till en introduktionskurs i programmering.
4.4.2 Utveckling, intervention och utvärdering
Indentering
Tidigare problem med indentering löstes genom att ändra konfigurationsfilen för analysverktyget CheckStyle. Genom att godta indentering som fyra stycken blanksteg samt lägga till detta värde för tabbredd under modulen TreeWalker klarar analysverktyget att använda både blanksteg och tabbtecken vid indentering.
Sekventiell testning
För att inte alla test för en klass ska exekveras samtidigt sattes ‘@Ignore’ annotation in i testklassen framför alla metodtest utom det inledande, vilket innebär att dessa tester kommer att bli temporärt inaktiverade och inte exekveras av när buildverktyget kör igenom testfilen. Med denna tillämpning kan studenten arbeta med ett test i taget och successivt fortsätta med nästa test efter att föregående har godkänts genom att ta bort ignoreannotationen metod för metod.
Enhetlig feedback
Eftersom en kommandoprompt redan används för att exekvera kodanalysen genom buildverktyget, bör ett rimligt tillvägagångssätt, på en prototypnivå, vara att få feedbacken sammanfogad i prompten. Efter att ha utforskat möjligheterna hittades ett pluginet vid namn gradlequalityplugin. Med pluginet var det möjligt att dels använda samtliga valda analysverktyg och få dessa printade direkt i prompten istället för att generera tre olika rapporter.
Figur 7 Enhetlig feedback
4 Checkstyle rule violations were found in 1 files
[Whitespace | EmptyLineSeparator] JamnaTa.(JamnaTal.java:12) 'METHOD_DEF' should be separated from previous statement.
http://checkstyle.sourceforge.net/config_whitespace.html#EmptyLineSeparator
[Blocks | NeedBraces] JamnaTa.(JamnaTal.java:14) 'if' construct must use '{}'s.
http://checkstyle.sourceforge.net/config_blocks.html#NeedBraces
[Indentation | Indentation] JamnaTa.(JamnaTal.java:15)
'if' child have incorrect indentation level 9, expected level should be 12.
http://checkstyle.sourceforge.net/config_indentation.html#Indentation
[Indentation | Indentation] JamnaTa.(JamnaTal.java:17)
'method def' child have incorrect indentation level 9, expected level should be 8.
http://checkstyle.sourceforge.net/config_indentation.html#Indentation
