Poäng. Start v. Applikationsutveckling i Java 7.5. Antal registrerade (män/kvinnor) 131 (119/12)

Transkript

1 TEK/NAT Kursrapport Kurs Kurskod Poäng År Start v. Applikationsutveckling i va 5DV Institution Institutionen för datavetenskap Antal registrerade (män/kvinnor) 131 (119/12) Antal aktiva studenter (deltagit i minst en examinerande del) 128 Genomströmning (i %) och betygsutfall efter första tillfälle för examination (för varje betyg som satts på kursen ange antal som uppnått detta på formen??? Genomströmning: 35% Betyg: U(86) 3(19) 4(21) 5(5) Hur mycket schemalagd lärar-/assistent-ledd tid har studenten tillgång till på kursen? 15 föreläsningstillfällen a 2h, 3 gruppövningstillfällen a 2h, Samt två muntliga redovisningstillfälle. Utöver detta har ett antal schemalagda handledningstillfällen funnits. Totalt sett har 498 timmar lärarresurser funnits allokerat till kursen Hur är undervisningen upplagd? Föreläsningar, gruppövningar och handledning har funnits för studenterna. Under en del av kursen har studenterna jobbat i grupp (ca 4 personer) i ett projekt. Kursen har examinerats via 2 enskilda laborationer, projektet (som redovisades vid fyra olika tillfällen muntligt och skriftligt ur olika aspekter), samt en tentamen. För vart och ett av lärmålen (FSR:en) i kursplanen, beskriv kortfattat hur det examineras. värdera och välja lämpliga konstruktioner för applikationsprogrammering i ett objektorienterat språk (FSR1), Labbar ur ett objektorienterat mjukvaruperspektiv förklara en tråd, hur de skapas, hanteras och avslutas samt kritiskt analysera datatyper och objekt samt tillämpa synkronisering för att uppnå trådsäkerhet (FSR2), Labbar + tentamen förklara vanliga designmönsters uppbyggnad och använda dessa vid utveckling av mjukvara (FSR3), tentamen + labbar beskriva en traditionell projektmodells delar och samt hur dessa samverkar (FSR4). i enlighet med en traditionell projektstyrningsmetodik vara en aktiv deltagare i en grupp och genomföra ett programmeringsprojekt samt presentera detta (muntligt och skriftligt) (FSR5), konstruera program med händelsestyrd programmering genom användandet av grafiska användargränssnitt, samt utvärdera dessa enligt vedertagna analysmetoder (FSR6), labbar/projekt inkludera strukturerad datahantering (exempelvis XML) i mjukvarulösningar (FSR7), och en laboration samt tentamen använda sig av testdriven utveckling (TDD) (FSR8), /tentamen använda sig av UML-notation för att beskriva statiskt och dynamiskt beteende för en design/ett program (FSR9). labbar/projekt samt tentamen analysera den egna förmågan att arbeta i grupp och i projekt (FSR10), analysera egna styrkor och svagheter vid muntliga presentationer (FSR11). reflektionsrapport knuten till. Beskriv hur betygssättningen på kursen fungerar. (Vilka betyg ges på kursen och hur sker bedömningen, dvs vilka delar betygssätts och hur vägs de samman? Finns det skrivtliga betygskriterier och/eller lärmål (FSR) för de olika betygen?) Kursen har 2 moment. Ett teorimoment som examinerats via en tentamen. Tentan har varit uppdelad i 3 delar som tillsammans med resultat på labbarna ger slutbetyget Samläses denna kurs med andra kurser?? Om ja, hur många?

2 Hur stor andel av kursen samläses? Samläser flera program denna kurs? Om ja, hur många? 2+ Arbetar studenterna i projektform på kursen? Om ja, uppskattad omfattning i poäng på projektdelen: 2 Antal projekt som varje student deltog i: 1 Antal studenter i projektgrupp: 4 Förväntades studenterna använda en projektmetodik för dokumentation och styrning (tex LIPS)? Hur skedde indelning av studenter i projektgrupper? Kursledning gjorde indelning Har studenterna uppmanats föra projektdagbok? Om ja, Har dagboken utgjort grund för examination? Kursens samverkan med forskning Ingen samverkan med forskningsverksamhet förekommer på kursen Annan samverkansform, nämligen: Kursens samverkan med näringsliv eller offentlig verksamhet Ingen samverkan med näringsliv/offentlig verksamhet förekommer på kursen Annan samverkansform, nämligen Genomförda förändringar till detta kurstillfälle Förändringar i hur kursen betygssätts, förändringar i labbarna ordning, mindre förändring i labbarna, samt en del förändringar i kursinnehåll. Förändringsförslag från föregående kursrapport Lärare Information om inblandade lärare Kursansvarig n Erik Moström Antal övrig personal som ej föreläser 4 Antal övriga föreläsare 1 Hur stor del av den schemalagda tiden på kursen undervisas av forskande lärare (dvs lärare med mer än 25% forskning i sin tjänst)? 0 Hur stor del av den schemalagda tiden på kursen undervisas av lärare verksamma i näringsliv/offentlig verksamhet (dvs lärare med mer än 25% av sin tjänst förlagd till näringsliv/offentlig verksamhet)? 0

3 Kursvärd. Totalt antal svarande 32 Sammanställningsdatum När genomfördes kursvärderingen? Efter genomfört första examinationstillfälle För varje lärmål på kursen ange hur stor del av de studerande som uppger att det har behandlats på kursen - ange svaret i procent på formen har behandlats/har inte behandlats/vet ej värdera och välja lämpliga konstruktioner för applikationsprogrammering i ett objektorienterat språk (FSR1), 100 ur ett objektorienterat mjukvaruperspektiv förklara en tråd, hur de skapas, hanteras och avslutas samt kritiskt analysera datatyper och objekt samt tillämpa synkronisering för att uppnå trådsäkerhet (FSR2), 91/3/6 förklara vanliga designmönsters uppbyggnad och använda dessa vid utveckling av mjukvara (FSR3), 91/6/3 beskriva en traditionell projektmodells delar och samt hur dessa samverkar (FSR4). 81/13/6 i enlighet med en traditionell projektstyrningsmetodik vara en aktiv deltagare i en grupp och genomföra ett programmeringsprojekt samt presentera detta (muntligt och skriftligt) (FSR5), 97/3/0 konstruera program med händelsestyrd programmering genom användandet av grafiska användargränssnitt, samt utvärdera dessa enligt vedertagna analysmetoder (FSR6), 100/0/0 inkludera strukturerad datahantering (exempelvis XML) i mjukvarulösningar (FSR7), 100/0/0 använda sig av testdriven utveckling (TDD) (FSR8), 97/0/3 använda sig av UML-notation för att beskriva statiskt och dynamiskt beteende för en design/ett program (FSR9). 69/13/19 analysera den egna förmågan att arbeta i grupp och i projekt (FSR10), 94/0/6 analysera egna styrkor och svagheter vid muntliga presentationer (FSR11). 88/0/13 Sammanf. Sammanfattning av åsikterna i kursvärderingen - positivt och negativt kring föreläsningar, seminarier, grupparbeten, laborationer, examination etc

4 Positivt: labbarna, A-B-C strukturen på tentan, projektet var bra, bra att grupperna slumpas, bra föreläsningar, det mesta, ordningen på labbarna - de bygger på varandra, kanske korta ner lab 1-2, code reviews, workshops, grupparbetet, designpatterns, relevant, bra att det inte bara är tentan som spelar roll för betyget. Bara själva uppgiften har varit bra. Förbättringar tenta: Dåligt utformad tenta, dåligt formulerade frågor, Tentan var extremt oklar och poängen kändes helt orimlig. En fråga på 3p krävde typ två meningar och en fråga för samma poäng 2 a4. Enligt mitt tycke var tentans nya upplägg inte så bra då minsta lilla slarvfel leder till att man blir underkänd. Då jag kunde frågor på B-delen men då kändes inte dessa lönt att skriva när man kände sig så osäker på om man klarat A-delen. Tycker dessutom att många frågor på A- delen var otydliga. Känns omotiverande då det krävs 90% rätt på A-delen för att få godkänt då frågorna inte kan bedömas som endast rätt/fel. Om tentan nödvändigtvis skall vara uppdelad på detta sätt bör A-delen bestå av kryss-frågor och sant/falskt-frågor. Tydligare tentafrågor. Tenta poäng systemet var väldigt konstigt, man kan ju inte skriva "dvs 5 poäng på nivå A behöver inte ha samma värde som 5 poäng på nivå b." Detta tyder ju på att poängen är väldigt subjektiv. Vilket inte borde vara fallet under en tenta, borde stå rakt av på tentan vad man kan få för poäng och vad som krävs för de olika betygen. Gränserna på tentan som var nya för denna kurs kändes orealistiska Tentan - Formatet går att ifrågasätta. Anledningen, enligt föreläsaren, till detta format var att man inte ska få godkänt p.g.a ströpoäng. Hans exempel var att om man stavar "while" rätt om man ska skriva kod så kan man få poäng som leder till godkänt på tentan. g anser att dena logik är väldigt konstig. Då är det väl bara att inte ge poäng för att stava "while" rätt?! Enligt detta format kan man ha otur och missa något man egentligen kan och då inte få 90(!!!!!)% rätt på första delen MEN man har varit väldigt duktig och fått 100% rätt på de två andra delarna. Enligt föreläsaren så rättar han inte ens de andra delarna om man misslyckas med det första. Alltså, enligt detta format, så är man inte kunnig nog på denna kurs TROTS att man har alla rätt förutom 1.5 poäng på del A (som man kan ha otur på). Om del A på tentan kräver 90% är det kanske bättre med kortare frågor, känds lite orimligt om man måste skriva en halv novell bara för att svara på en fråga. Tentaupplägget kändes ganska vettigt med olika delar för olika betyg, men det kändes också som att gränsen på 90% på "A-delen" var för hög och att den antingen borde sänkas alternativ att man kan väga upp till viss del m.h.a. de andra delarna. Det måste vara tydligare krav på labbarna, handledare ska inte kunna komma och ge en O för grejer som man inte ens visste om skulle göras. Sedan tycker jag att provet kunde ha varit bättre upplagt. Tycker själva principen att dela upp provet i tre delar var bra. Men tycker att ifall man ska ha 90% gräns på den första delen så ska det vara entydliga och relativt "snabbsvarade" frågor. Förbättringar labbar: På föreläsningen är fokuset på struktur och designmönster hög. Dock är den låg på labbar, samtidigt så är det väldigt lite tid för att lägga till fler labbar. Det har varit för lite handledning i kursen. g har suttit på flertalet handledningar utan att få hjälp och unde projektet fanns nästan inga tider alls. Det har vart alldeles för hög detaljnivå på inlämningauppgifterna så att något som man fock läsa mellan raderna avgjorde mellan G och O. Viktiga krav till uppgifter borde stå tydligt i specen. Det vore trevligt om tidsplaneringen och hur man bäst bokför sina timmar hade mer tid under workshopförklaringar. Labbspecifikationer klara i god tid. Inte tillägga krav o. dyl. efter labbens start. Projektgrupperna skulle kunna slumpas fram på ett annat sätt en nu. Vid bedömning av labbar fokusera på det som faktiskt är intressant istället för saker som cachning. Om specifikation lämnar utrymme för tolkning så är det endast onödigt att ta ställning vid bedömningen. Saker är intressant att få feedback/bedömning på är tex trådning, design och patterns. Det skulle vara trevlig att om det läggs upp felaktigt kod på git, kod som användes under workshops för att diskutera vad som bör ändras, att det senast efter workshopen också finns en rättade version på git så att man kan ta del av informationen om man inte har kunnat gå på workshops. Dessutom skulle det vara trevlig att handledarna ger samma information och inte att man får olika information beroende på vilken handledare man prata med. Att ha kodreview låter bra men det kanske är bättre att ha det på morgonen samma dag som koden ska in istället för några dagar innan, eftersom det kom folk på tillfällen som knappt hade skrivit en rad kod som skulle kunnas kollas över. Workshops i sig låter väldigt bra dock slutade jag gå på de eftersom de inte verkade vara bra förbered, eller så hade jag bara otur med vilken handledare jag fick. Resultat från rättningen av gruppinlämningar får gärna skickas ut till alla, annars är det för lätt att ett K eller O missas. Lär gärna ut mer om saker som kan behövas i projektet, typ en lektion kring jar-filer och hur man laddar in resources i denna. Bättre beskrivning av vad som kan komma till att behövas i en pom-fil (specifikt för projektet). Databas obligatoriskt. Som vanligt så uppdateras spec för labbar alldeles för mycket. Otydliga formuleringar som går att tolka olika. Borde vara solklart efter att man läst specen gånger. Men tydligen inte. Laborationerna - Väldigt tidskrävande p.g.a massor av små onödiga krav som endast tar tid. Det räcker med att man känner till t.ex TableModel och alla dom sakerna, istället för att man ska gräva sig in i det när man har andra kurser som också tar tid. Förbättringar föreläsningar: vissa föreläsningar kändes irrelevanta. pga. upprepning, poänglöst teman m.m. Vissa av föreläsningarna kändes välmenande, men kanske inte relevanta. Vid något tillfälle togs kata/kator upp och jag lyckades inte koppla det till kursen eller vad jag skulle använda det till eller hur det skulle utföras. Lärarnas synpunkter på kursens innehåll och genomförande Innehållet är OK, dock så vissa saker tas bort/förkortas med andra delar kan få en mer detaljerad genomgång. Labbarna är OK men själva genomförandet behöver styras upp utan att för den delen bli för detaljerad - meningen är att uppgifterna ska vara lite "lösare/otydligare" än i tidigare kurser. Examinationen har ändrats så att för att klara kursen ska studenterna klara FSR-kraven, inte genom att samla ihop ströpoäng på olika uppgifter och därför komma över gränsen. Eftersom detta var första gången så finns det utrymme för att förbättra själva utformning av frågor etc men jag är av åsikten att strukturen ska behållas. Förslag till nästa kurstillfälle - ange vem som ansvarar för förändringen Polera på genomförandet av labbarna - inklusive handledning, workshops och code reviews. Föreläsningarna - justera innehållet en del. Examination - behåll strukturen men polera på frågorna Ansvarig: kursansvarig Bör kursplanen ändras till nästa kurstillfälle - vem ansvarar i så fall för att förändringen görs?

5 Granskn. Granskare lärare (CAS-identitet) jamo0001 [Moström, n Erik] Granskare student (CAS-identitet) leka0001 [Kallin Westin, Lena] Granskare studieadministratör (CAS-identitet) leka0001 [Kallin Westin, Lena] Eventuella kommentarer på granskningsprocessen saknar student