Av lärarnas svar går det att utläsa ett flertal saker. Den första av dessa relaterar till den första frågan, gällande den mängd plagiat som upptäcks var termin. De lärare som inte aktivt letar efter plagiat hittar endast enstaka fall, medan de som lägger mer arbete på det regelbundet hittar fler fall. Detta går att koppla till nivån på programmeringskurserna som lärarna håller. Rolf och Magnus, som mindre aktivt letar efter plagiat, håller i fler kurser på introduktionsnivå. Johan och Farid håller däremot i fler kurser på mer avancerad nivå, där arbetet med att leta efter plagiat uppenbarligen ökar. Det här kan tolkas som att ett automatiserat verktyg för att upptäcka plagiat kan både vara lämpligt att använda på mer avancerade kurser samt kurser på introduktionsnivå. På mer avancerade kurser kan det påskynda granskningsarbetet och hjälpa lärarna med att upptäcka de fall av plagiat som faktiskt finns. På introduktionskurser kan det istället användas i huvudsak för att påskynda arbetet med att analysera inlämningarna. I vidare diskussioner av de frågor som ställdes går det även att tyda att lärarna anser att plagiat inte är lika relevant att upptäcka i introduktionsuppgifter jämfört mot större, eftersom att de har färre unika lösningsalternativ. Arbetet med att upptäcka plagiat i sådana enkla uppgifter fyller inte heller något direkt syfte, då det framkommer i intervjun med Hans att bevisningen kan bli svår. Detta då studenter enkelt kan skylla på det begränsade antalet unika lösningar uppgiften har, vilket även tas upp av Frew och Mann [8], vilket tidigare nämns i avsnitt 1.1.3. I sådana fall vore det mer praktiskt att, likt det Magnus och Johan tar upp, istället använda ett verktyg som kontrollerar om programmen är körbara.
Det andra som går att utläsa från lärarnas svar relaterar till vilken sorts plagiat de anser vara mest förekommande. För kurser på introduktionsnivå var det vanligast med direkta kopior, vilken är den första metoden av de åtta Martins m.fl. definierat [9] och är den minst avancerade för en student att använda. Farid som håller i mer avancerade kurser, menar även han att direkta kopior är vanligast, medan kod som strukturerats om ofta passerar obemärkt. Johan anser att kopior med små förändringar i exempelvis kommentarer är den mest förekommande varianten, då studenter ofta undervärderar lärarens intelligens. Han nämner ett sådant fall, där studenten i fråga använt tidigare skriven kod utan att lyckas dölja det. Specifikt hade studenten tagit kod från internet publicerat på GitHub och sedan ändrat kommentarer, men glömt att ta bort medföljande copyright-fil som inkluderats i nedladdningen. Johan förklarar också att fusk kan misstänkas utöver granskningsarbetet av källkod. Misstankar om att studenten försöker dölja något kan också väckas i situationer där inlämningen har en okonventionell filstruktur eller att kodfiler namngivits med egendomliga namn. I källkod upptäcker även Johan fall av plagiat i form av direktkopiering med liten omformulering, såsom ändrade
kommentarer och metodnamn. Tidigare påstående av Joy och Luck [5] menar att studenter i liknande situationer som kopierar och redigerar en kamrats program vanligen gör lexikala ändringar i koden [5]. Författarna menar därför att stor vikt bör läggas på att ett verktyg upptäcker lexikala ändringar samt några strukturella, vilka är mer avancerade [5] för en student att använda. Exempel på lexikala metoder är Martins m.fl.:s andra och tredje varianter av plagiat, vilka är att kommentarer ändras eller tas bort respektive att variabel- eller metodnamn ändras [9]. Johan nämner också att studenter kan ha skrivit gemensam kod för en individuell uppgift, vilket leder till likartade inlämningar. Detta nämns också av Frew och Mann, som menar att studenter ofta inte ser samarbete som fusk, vilket kan leda till att en student utan nödvändiga kunskaper kan klara av en uppgift [8]. Johan menar att sådana fall för honom ofta är enkla att upptäcka, medan mer avancerat fusk, såsom Martins m.fl.:s femte metod för plagiat, där operander i likhetsjämförelser förändras utan att byta innebörd [9], möjligen missas. Vidare menar både Magnus och Rolf att det inte finns något direkt syfte med att straffa studenter för plagiat i introduktionsuppgifter. Istället anser de att studenter bör uppmuntras att ordentligt åta sig de programmeringskunskaper som krävs när plagiat upptäcks i sådana uppgifter. Även Farid anser att studenter bör ges en andra chans första gången de plagierar, då han menar att detta kan ses som ett misstag av studenten som kan bli en viktig läxa för den fortsatta utvecklingen.
Samtliga lärare är eniga om att resultatet måste presenteras på ett tydligt sätt, av ett verktyg. Resultatet måste visualiseras på ett sätt som snabbt kan efterbehandlas av läraren. Detta för att knyta vilka studenter som möjligen fuskat och även generera bevisning genom att peka ut de delar av koden som är likartade. Detta tankesätt gällande presentation stämmer överens med både Hage m.fl.:s [4] och Joy och Luck’s [5] åsikter för hur ett resultat bör visualiseras. Detta skapar i sin tur ett krav på att verktyget presenterar resultatet på ett godtyckligt sätt. Tre av lärarna önskade också att verktyget analyserar inlämningsuppgifterna på kort tid. Uttrycket ‘kort tid’ definierades inte exakt under intervjuerna, men svaren kan tolkas som att det inte får ta mer än fem eller sex minuter för verktyget att producera ett resultat. De här åsikterna kommer främst att användas för att senare i arbetet kunna besvara delfråga ett: “Vilken hjälp behöver lärarna på Malmö Högskola i sitt arbete med att upptäcka plagiat i källkod?”. Åsikterna bidrar även med användbart material för att senare kunna besvara delfråga två: “Vilket granskningsverktyg passar bäst för de behov som lärarna vid Malmö Högskola har?”.
För Magnus är det viktigt att ett potentiellt verktyg kan byggas ut för att hantera fler programmeringsspråk. Det kan även motiveras att den direkta användningen av ett automatiserat verktyg på ett universitet underlättas i fall verktyget har stöd för flera språk. Om verktyget redan stödjer flera språk kan det användas direkt i flera kurser, istället för att tid måste spenderas på att eventuellt bygga ut det med fler språk. Vid en jämförelse av det kvalitativa resultatet från Hage m.fl.:s [8] och Martins [10] som presenteras med hjälp av en matris som visar vilka egenskaper verktygen stödjer, ges intrycket att det kan ta lång tid att lägga till nya språk för ett verktyg. Detta går möjligen att påvisa genom att jämföra antalet språk verktygen stödjer arbetena emellan. För de gemensamma verktygen som behandlas i de båda artiklarna stödjer bland annat verktyget SIM fem språk i Hage m.fl.:s artikel från 2011 [8]. Fem år senare i Martins artikel från 2016 stödjer SIM istället sju språk [10], vilket antyder att utvecklingen för att inkludera ytterligare språk kan vara en utdragen process. Ytterligare ett tecken på detta kan göras med att se hur många nya språk JPlag har fått stöd för efter att det publicerades som öppen källkod 2015. Två år efter dess publikation har verktyget även fått stöd för programmeringsspråket Python, vilket
nämns i avsnitt 3.1.4. På grund av att det kan vara tidskrävande att bygga ut ett verktyg med fler språk, kombinerat med det faktum att programmeringskurserna på Malmö Högskola använder flera olika programmeringsspråk skapas ett nytt krav. Detta är att ett verktyg ska klara av att hantera ett godtyckligt antal programmeringsspråk, vilket bör leda till en mindre tidskrävande process vid införandet av ett nytt verktyg. I det här resonemanget tillförs viktig indata för att kunna besvara delfråga två: “Vilket granskningsverktyg passar bäst för de behov som lärarna vid Malmö Högskola har?”.
Slutligen går det att utläsa att samtliga lärare som intervjuats är positivt inställda till ett dokument för att hjälpa granskningen av källkod. De menar alla att detta skulle kunna hjälpa dem vid potentiella bevisningar för disciplinnämnden. Detta genom att ge dem exempel som de kan visa upp och jämföra med. Ett hjälpande dokument skulle därför kunna ses som en tillförlitlig lösning på de bevisningsproblem som uppstår när en person utan programmeringskunskaper ska ta det avgörande beslutet om plagiat har begåtts eller inte. Svårigheterna med att bevisa tydliga fall av plagiat för någon utan sakkunskaper i ämnet framkommer även i Modiba m.fl.:s forskningsartikel [12] som ett problem, vilket tidigare nämns i avsnitt 1.1.5.