How the IOOPM Course Works

Completely new Assignment 1

Assignment 1 is now a cross-breed of traditional labs and traditional assigments. The idea is to provide some more safety and also steer thoughts a bit, but not have small tasks that are too well-aligned to one or two specific concepts.

Overhaul of Assignment 2–4

Based on outcome of assignment 1. FEEDBACK, people!

New course website

Toning down reliance on GitHub. Also, no markdown which is a huge boon for me…

Stricter group meetings, with coaches

As described here.

New vagrant machine for using own laptops/computers

As described here.

Changed Emacs shortcuts and settings

As described all over the place.

New lecture material on some lectures

Generally freshening things up and aligning content with assignment 1.

Queuing time on labs

Probably not solved (but you’re fewer this year).

1. Two projects (but the simpler one needs beefing up)
2. Survey for finding project groups

Kursen är uppdelad i tre faser, fas 1, 2 och 3. Fas 1 och 2 behandlar imperativ programmering exemplifierad med C respektive objekt-orienterad programmering exemplifierad med Java. I dessa faser arbetar du i ett kodpar med en annan person. Mellan varje inlämningsuppgift kommer du att rotera partner. Fas 3 är ett projektarbete med 4-6 personer.

• Fas 1 och 2 är indelade i 2 sprintar vardera. Varje sprint är 2 eller 3 veckor lång (se deadlines).
• Indelningen av fas 3 i sprintar samt sprintarnas längd bestäms av projektgruppen.

Varje sprint har ett antal uppgifter knutna till sig. För varje sprint inom samma fas växer kraven på uppgifterna som också blir mer komplicerade, och du får fler uppgifter att välja mellan. För att bli godkänd på kursen måste du göra minst en uppgift per sprint.

För att bli godkänd på kursen kommer du att behöva demonstrera att du uppnått alla kursmål (detta gäller på alla kurser). För att göra det tydligt arbetar vi med att separera inlämningsuppgifter från de kursmål de (är tänkta att) examinera. Det betyder att syftet med att göra en inlämningsuppgift inte är att “skriva ett program som…” utan att koppla programmet mot kursens mål och använda programmen som du skriver för att visa att du uppnått målen.

Du utgår alltså från uppgifter (i olika grad av förfärdigande beroende på när du redovisar) när du redovisar mål, och det skall finnas en tydlig koppling till uppgiften eller någon föreslagen utökning till uppgiften. Det ingår i uppgiften (eller egentligen i hela kursupplägget) att förstå mappningen från uppgift (eller del av uppgift) till lämpliga mål. Vi ger ibland förslag, men färre och färre ju längre in i kursen vi kommer. Det räcker inte med att bara följa förslagen för att bli godkänd, utan du måste själv ta reda på/förstå vilka mål du bör redovisa och när.

Målen redovisar du i stort sett uteslutande på labbarna (ca 8 timmar varje vecka). Till labbarna kan du också gå för att få hjälp. Försök att alltid redovisa mål i sammanhängande klumpar.

För varje mål anges vilken nivå målet ligger på och hur det kan redovisas. 2018 finns ca 43 mål på nivå 3, 18 mål på nivå 4 och knappt 8 mål på nivå 5. Av de 43 målen på nivå 3 avser 4 mål avklarade inluppar och 6 mål redovisas i och med projektet.

Du måste bocka av mål löpande under kursens gång. Det är ca 25 labbar att redovisa på och totalt 55 mål att redovisa på labbar (för nivå 5). Det finns ett maxtak på 4 avbokade mål per labbtillfället – du måste alltså redovisa på minst 17 labbar för att få betyget 5.

För att bli godkänd på kursen måste alla mål vara godkända, och kodprovet avklarat. För att få betyget 3 på kursen måste samtliga mål på nivå 3 vara uppfyllda, för betygen 4 måste samtliga mål på nivå 3 och 4 vara uppfyllda och för betyget 5 måste samtliga mål vara uppfyllda. Observera att det inte finns en linjär relation mellan antalet mål och tidsåtgång – och många mål kan bockas av samtidigt och inom ramarna för samma uppgift.

Notera att du förväntas att själv söka efter information, både i de länkar och bokreferenser som finns i kursmaterialet, men också fritt med hjälp av t.ex. Google och Wikipedia. Föreläsningarnas syfte är att måla en övergripande bild och introducera viktiga koncept och ibland även göra praktiska övningar.

This course does not follow any specific book. If you like following books (great!!!), please come talk to me and we can discuss what kind of book would be good for you. The course goes on forever, so no sweat if you don’t have a book the first 1-2 weeks!

Under kursens gång kommer du att ingå i en framslumpad arbetsgrupp med ca 10-12 personer. Dessa grupper byggs successivt upp under kursens första vecka i takt med att vi får namnen på alla registrerade studenter från IT-kansliet. Ur arbetsgruppen får ni fritt skapa kodpar om två personer med kravet på att rotera partners mellan varje inlämningsuppgift och att inger får ha samma partner mer än en gång under fas 1 och 2. Anledningen till att du själv skall välja par beror på att du i möjligaste mån vill arbeta med någon annan i samma grupp med liknande intressen och ambitioner.

Allt arbete på kursen sker tillsammans med någon annan i ett programmeringspar. Paren kommer också i regel att redovisa tillsammans, oavsett om dessa redovisningar sker i labbsal eller på annat sätt. Alla bedömningar är individuella och det är möjligt att en student blir godkänd och en underkänd på samma redovisning. Det är också möjligt att ha en redovisning där endast en student bockar av högre mål, etc.

With few exceptions (essay, C7, communication and project achievements), demonstrations take the form of oral examination in front of a computer terminal with one examiner and two students working in a pair.

Checks are individual, meaning that both respondents must demonstrate mastery for both to pass. A mostly passive respondent will not pass a check even with a brilliant partner. The responsibility for making sure that both respondents actively participate is on the respondents – not on the examiner. For this reason, and because it tends to speed things up, we encourage you to prepare your demonstrations and discuss who says what. In our experience, this makes demonstrations run faster, have higher quality, and increase your reflection (e.g., you will remember it better).

The choice of oral examination serves several purposes. Explaining interactively is time-efficient, both for you and us, and feedback is given immediately when the demonstration is still fresh in your mind. Technical communication is an important soft-skill that is trained automatically in this setting.

Demonstrations take place in 1515, 1549 and (for students with laptops also 1245), during the lab sessions, excluding bootstrap labs (where you will be demonstrating lab tasks instead). You request to demonstrate through the AU Portal where you can choose which achievements you wish to demonstrate.

After requesting to demonstrate, there will be a waiting period (so please do continue to work). A feed of pending requests to demonstrate is shown on a screen to the TAs, who claim demonstrations before dispatching to where you are located. Modulo reasons, demonstrations are picked up in the order they were requested.

You can see on the web page when your request has been picked, up and by whom. At all times, you can also see how many requests are waiting and how many are in front of their request, if any. You cannot queue several simultaneous requests.

When the examiner arrives, you must pitch your demonstration, which means:

1. Stating what achievements you wish to demonstrate
2. Explaining why/how it makes sense to demonstrate them together
3. Explaining what evidence you will use in the demonstration

If the examiner is not satisfied with 1 or 2, she will explain why and reject the request.

By evidence, we mostly mean artefacts developed in the course that will form the basis of the demonstration. For example, “we profiled the binary search tree that we developed in Assignment 2”. The key idea with evidence is that you relate the achievements to the programming assignments (and programming project) of the course¹. Expect to be asked questions that force you to go “off-script”, e.g., what would happen if \(X\) is changed for \(Y\), or the examiner asks you to change some lines of code, or introduces a bug etc.

If the examiner finds the answer to 1–3 satisfactory, she will hand over the running of the demonstration to you! Different examiners approach this task differently. Some will interrupt and ask questions. Some delay all questions to the end.

Only the achievements explicitly stated at the beginning of the demonstration can be passed in the demonstration. If you were to happen to ``meet the requirements’’ for some other achievement too, this achivement will not be marked as done. Actually, we will not even tell you if you didn’t see it yourself! Our philosophy is that you can only know what you know you know, meaning that accidentally demonstrating procedural abstraction not knowing that that is what you are doing counts as nothing. (We are not sadists either so expect to get nudged towards the relevant insight.)

Each achievement in your demonstration will be marked as either pass, fail or fail with push-back. If you fail to demonstrate an achievement, you are free to try again whenever you like. A fail with push-back indicates a deep misunderstanding of something, which blocks you from re-attempting demonstration for the rest of the lab session to encourage spending some more time understanding that achievement. Failures with or without push-back are not counted towards any grade.

An examiner’s decision is final, and the examiner does not “have to” motivate failing a presentation. Examiners are however expected to explain and motivate both passing and failing grades on demonstration.

Vid sex tillfällen under kursen kommer du att kallas till ett kort uppföljningsmöte där du (och din labbpartner) får presentera hur det går för er i den pågående sprinten. Där kan ni visa vad ni har gjort hittills och vad ni planerar att göra resten av sprinten. Tanken med dessa möten är att ni ska kunna få hjälp att hålla en lämplig styrfart genom kursen och att komma loss om ni har kört fast. Om ni är osäkra på vilka mål som passar med er uppgift kan får ni diskutera saken med en assistent och ett annat programmeringspar. Läs mer här.

Hela kursens finns det ungefär 8 timmar schemalagd i datorsalar per vecka, s.k. labbtillfällen. Deltagande vid dessa tillfällen är inte obligatoriskt (förutom inledande 6 C-labbar och 3 Java-labbar). Vid dessa tillfällen finns det möjlighet att få handledning och också möjlighet att redovisa mål (förutom inledande 6 labbar).

Mer information om labbarna och redovisning finns här.

Målen har en betygsnivå kopplad till sig. Mål på högre nivå omfattar de på lägre nivå. Du kan inte byta ut ett mål på en högre nivå mot ett mål på en lägre nivå (det vore inte vettigt).

• För att få betyget tre måste du klara av alla mål på nivå 3.
• För att få betyget fyra måste du klara av alla mål på nivå 3 och 4.
• För att få betyget fem måste du klara av alla mål på nivå 3, 4 och 5.

Kursen ger totalt 20 hp uppdelat på fem delar:

• 2.5 hp för kodprovets imperativa del (C)
• 2.5 hp för kodprovets objektorienterade del (Java)
• 5 hp för inluppar 1 avklarad
• 5 hp för inluppar 2 avklarad
• 5 hp för projektet avklarat

Observera att om du klarar av alla mål på nivå 3 och uppfyller alla krav på projektuppgiften får du 15 HP (dvs. alla utom kodprovet).

Vilket betyg vill du ha? Du styr själv vilket betyg du vill uppnå – vilken nivå av insikt vill du nå, etc.? Målen på nivå 4 och 5 speglar djupare insikter eller högre kvalitet med avseende på olika kursmål. Om du vill nå betyget 3, 4 eller 5 måste du bestämma dig för det och aktivt arbeta för att nå dit. Fatta ett beslut. Du kan ändra dig senare. För att minska stressen kan du redan nu planera in en tidpunkt (t.ex. 1:a oktober) för att eventuellt revidera beslutet.

Hur blir du godkänd på en kurs? Det går inte att arbeta på att “bli godkänd”, det är för flummigt och abstrakt. “Problemet” måste brytas ned i mindre beståndsdelar (delproblem) och kanske även bryta ned dessa ytterligare för att nå tillräckligt konkreta proble/uppgifter som faktiskt går att tackla.

Du har redan fattat beslut om vilket betyg du vill ha. Då vet du också vilka mål du måste klara av. Det är dina hyfsat konkreta uppgifter.

Exempel: Låt säga att du satsar på betyg 7 och att det omfattar totalt 42 mål. Du tittar igenom målen och ser att 8 är knutna till projektet. Ytterligare 4 mål verkar rimliga att redovisa i samband med projektet (så vitt du förstår) eller via andra aktiviteter. Då kvarstår 30 mål som skall redovisas under fas 1 och 2.

Det är totalt 5 sprintar under fas 1 och 2. 30 genom 5 är 6. Det betyder att du måste klara av 6 mål varje sprint för att ha 12 kvar när projektet börjar.

6 är den styrfart (velocity) som du skall ha i snitt per sprint för att komma i mål. Det betyder 3 mål per vecka och i snitt 1,5 mål per labbtillfälle. Det är ganska troligt att du inte kommer att redovisa 1,5 mål varje labbtillfälle, eller ens 3 mål varje vecka. Verkligheten fungerar ofta så att vi gör framsteg på flera saker, och sedan klarar av många på ett bräde. Om du gjorde en graf där Y-axeln var antal återstående mål och X-axeln var tiden skulle det “idealiska” vara en rät linje med start i (0,30) och slut i (5,0). Verklighetens kurva kommer att se annorlunda ut.

En graf av detta slag kallas för en burndown chart, och du kommer att göra flera sådana under kursens gång. En burndown chart är enkel att tolka och ger direkt en känsla för om det “går bra” eller inte – kommer jag till slut att komma i mål på utsatt tid?

I exemplet planerar vi utifrån förutsättningen att alla mål tar lika lång tid. Det är naturligtvis inte sant. Ett mer raffinerat sätt att planera tar varje uppgift (mål i detta fall) och tilldelar det ett antal “story points”, som är ett relativt mått på hur den uppskattade tiden att implementera delen. Kanske de 30 målen skulle motsvara 65 story points, och då skulle vår styrfart vara 13 story points istället för 6 mål (som alltså motsvarar samma arbete, bara uttryckt i en annan enhet). Om du för varje avklarad uppgift matar in dess “faktiska story points” får du automatisk återkoppling på din egen skattning och kan justera för att du t.ex. tenderar att underskatta svårigheter, etc. Du kan också planera med arbetstimmar istället för story points (men arbetstimmar är absoluta i tid vilket story points inte är).

För dig som tycker att det mesta på kursen är nytt kan det vara vanskligt att försöka avgöra om ett visst mål är värt 1 eller 3 story points. Då är det bättre att planera i enheten avklarade mål, åtminstone till en början.

Så länge vi håller styrfarten behöver vi inte planera för vad vi skall göra resten av projektet (kursen), utan kan fokusera på den aktuella sprinten. Varje sprint skall du göra en inlämningsuppgift och det är utifrån den uppgiften du skall redovisa mål.

Detaljplanering är alltså att bestämma sig för inlämningsuppgift och mål. Du kan börja i båda ändor: vilka mål har jag kvar och vilken uppgift verkar passa bäst, eller vilka uppgifter finns det och vilka mål verkar passa bra för dem? I början av kursen har du många mål och få uppgifter så då lämpar det sig bättre att börja med att bestämma uppgift först. Förmodligen är det en bra idé att vara halvklar med uppgiften innan du funderar över vilka mål du kan redovisa utifrån den. (Uppgifterna är designade utifrån målen och du kan alltid få hjälp med den mappningen senare. Det finns ingen anledning att stressa över detta!)

Under första sprinten finns det bara en uppgift att välja mellan: lagerhanteringssystemet. Det gör det lätt att “välja”. Om du följer SIMPLE-metodiken uppmuntrar den dig att göra en nedbrytning av specifikationen av uppgiften i delproblem etc., precis som kursen. Det betyder att du kan göra en separat plan för implementationen av lagerhanteringssystemet, som inte behöver bry sig om mål om du inte vill. Du kanske bryter ned lagerhanteringssystemet i 52 deluppgifter. Du och din partner lägger upp ett arbetsschema med 25 timmar under sprinten. Styrfart 52/25 = 2 deluppgifter per timme. Ett annat alternativ är att blanda mål och deluppgifter i samma plan.

Att lära sig att planera och följa upp planen är också en del av kursen så stressa inte över att det tar tid att göra. Det får ta tid. Det är också okej att inte lyckas med sin plan hela tiden – du är ju här för att öva. Om du inte är ärlig mot dig själv och andra i din planering lär du dig ingenting och vinner heller ingenting.

Planering är bra, men du måste också följa upp utfallet så att du kan justera hur du planerar i framtiden. Detta görs tillsammans med andra i teamet, och finns beskrivet här.

Ditt burndown chart visar trenden – vad har du för styrfart, och kommer du att nå ditt mål? Kanske blir du sjuk en vecka och tappar därmed styrfart och måste planera in att komma ikapp? Kanske går det bättre än vad du trodde och du får smak på att sikta på ett högre betyg? Eller tvärtom.

I slutet av varje sprint är det läge att göra en liten kort postmortem som sammanfattar hur det gick och hur verkligheten avvek från din plan. Det är högst personliga reflektioner som kan hjälpa dig att planera bättre nästa gång. Är du tidsoptimist? Etc.

Mot kursens slut kommer du att göra en mer djuplodande uppföljning och analys av arbetet har fungerat, och hur styrfart, stress, förväntat/eftersträvat betyg, etc. har ändrats under kursens. Detta redovisas i målet C7: Planering och uppföljning.

Vi rekommenderar att du använder ett verktyg för att hantera ditt arbete. Trello är ett gratis verktyg för att arbeta med Scrum-liknande processer. I Trello hanterar du listor med uppgifter på ett “bräde” och flyttar uppgifter mellan olika listor för att hålla reda på vad som är klart, vad som ligger i din backlog, vilka uppgifter som just nu utförs etc. Trello funkar bra både för individuellt arbete och grupparbete.

Vi har skapat två bräden som du kan kopiera. Bräde ett innehåller kursens alla mål i kategorierna TODO 3, TODO 4, TODO 5, Doing, Next och Done som du kan kopiera och använda för din planering. Det går dessutom att koppla Trello till tjänster som genererar burndown chart för dig. Bräde två är ett utkast till plan för det första lagerhanteringsystemet. Det är inte komplett, utan tjänar till att hjälpa dig att komma igång.

Du hittar våra Trello-bräden här.

De flesta inlämningsuppgifter har två deadlines, en mjuk och en hård. Den mjuka deadlinen avser det datum då vi tycker att du bör ha redovisat en uppgift. Den hårda deadlinen avser det datum då du måste ha redovisat. Den hårda deadlinen ligger alltid en eller två veckor efter den mjuka, och ofta i samband med en annan deadline.

Ett kodpar som missar en hård deadline blir kallad till ett uppföljningsmöte med obligatorisk närvaro för att diskutera anledningen och eventuella påföljder. Undvik att missa hårda deadlines!