- We use Zoom for live lectures, to connect students during pair programming, and connect students and teachers for help requests and demonstrations.
- We use YouTube to distribute any prerecorded lecture material.
- We use Cloud 9 to pair program, collaborativly edit code, and interact with examiners for demonstrations.
- We use Piazza as a forum to discuss, ask for help between labs, and for teachers to broadcast information.
- We use MatterMost as an interactive chat tool to ask questions during lectures, and for quick text chatting between students, and between students and teachers.
- We use the AU Portal during the scheduled lab sessions to request live help and demonstrate progress which will then take place over Cloud 9 and Zoom.
- We use GitHub to manage all code students write during the course, and to share code between students for pair programming.
- We do NOT use the Student Portal or Studium for anything on this course.
A lot of this is new for 2020, and we are learning and experimenting as we go. We appreciate your constructive feedback during the course.
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. 2020 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. (Observera att för enkelhets skull hanterar vi introlabbar i C och Java samt kodprov som om de vore kursmål.)
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.
The course does not use a traditional closed-book exam. Read this page for more information about he coding exam. You will get multiple shots at this exam throughout the course, and typically more throughout the year.
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. In 2020, these will happen remotely over Zoom, using Cloud 9 as a shared editor.
Demonstration results are individual, meaning that both respondents must demonstrate mastery in order for both to pass. A mostly passive respondent will not pass a check no matter how brilliant the partner is. 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
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:
- Stating what achievements you wish to demonstrate
- Explaining why/how it makes sense to demonstrate them together
- 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[fn::In the course’s initial instalment, we naively allowed
any code to be used in demonstrations prompting students to search
for code rather than write their own, or spending lots of time
trying to write a minimal program that could be used to
demonstrate a maximal number of achievements. While there are
merits to both these approaches, we are seeking to teach how to
write imperative and object-oriented code, which is why we added
the requirement of evidence in the form of assignments from the
course.]. Expect to be asked questions that force you to go
“off-script”, e.g., what would happen if
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.
This “mind-map style” diagram shows what we’re looking for (and not) in a presentation and also gives a checklist for passing.
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 10 timmar schemalagd per vecka, s.k. labbtillfällen. Deltagande vid dessa tillfällen är inte obligatoriskt men det är endast i samband med dessa tillfällen som du kan redovisa framsteg på kursen. Det är också då vi har ett större antal hjälplärare på plats.
Mer information om labbarna och redovisning finns här.
Hjälp under labbarna sker över Zoom där du (och eventuellt andra studenter) samtalar med någon lärare samtidigt som ni delar på en gemensam editor i Cloud 9. Du ber om hjälp i AU portalen och kan följa din plats i kön och få en notifikation när någon har svarat på din förfrågan.
För instruktioner för att dela din Cloud 9-instans med en annan student eller lärare, klicka 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).
- Två av Z-målen (inlupp 1–4) avbockade, och därutöver
- 15 “vanliga” avbockade mål på nivå 3 (du kan inte använda samma mål i flera faser)
- Inga eftersläpande repetitionsmål
- Resterande två av Z-målen (inlupp 1–4) avbockade, och därutöver
- 15 “vanliga” avbockade mål på nivå 3 (du kan inte använda samma mål i flera faser)
- Inga eftersläpande repetitionsmål
- Målen Y64–Y69 uppfyllda, och därutöver
- 4 “vanliga” avbockade mål på nivå 3 (du kan inte använda samma mål i flera faser)
- Inga eftersläpande repetitionsmål
Kursens upplägg härmar avsiktligt lättrörliga eller agila processer, främst Kanban och Scrum. Under projektdelen (fas 3) skall du och din projektgrupp själva lägga upp en plan, följa upp och revidera den, etc. Fram till dess kommer ni att öva genom att arbeta på motsvarande sätt med kursen. Vi betraktar kursen som ett projekt vars slutmål är att du skall vara godkänd med det betyg som du siktar på.
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 att se detta
automatgenererat för dig i AU Portalen. 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?
file:images/SampleBurndownChart.png
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!
Honesty and integrity are of utmost importance.
These goals are not at odds with being resourceful and working collaboratively. You should be resourceful and you should discuss your work in this course with others taking the class.
However, you must never misrepresent the work of others as your own. Nor may you ever parrot explanations of others, or paint insights of others as your own.
When helping others – as you should, also for your own benefit – avoid doing their work for them – help them get to the point where they are able to do their own work.
If you have taken ideas from elsewhere or used code sourced from elsewhere, you must say so with utmost clarity in the documentation of your assignment.
When in doubt, ask the head teacher.
Q: Jag har delar av IOOPM från före 2013 kvar! Hur skall jag göra?
A: Om du läste kursen innan den gjordes om 2013 så ska du
göra olika saker beroende på vad du har kvar. Oavsett vad bör du
börja med att skicka ett mejl till den ansvariga läraren och berätta vad du har
kvar, och att du har för avsikt att bli klar med kursen i år.
Om du har kvar enstaka inlämningsuppgifter i C (två eller färre) eller Java (två eller färre) så kan du göra dem nu. Ha alltid med uppgiftsbeskrivningen eftersom årets assistenter kanske inte vet vad en uppgift gick ut på. Saknar man fler än två uppgifter i C (eller Java) måste man göra om hela Fas 1 (eller Fas 2). Samma krav för att klara av kursen gäller som för nuvarande studenter.
Om du har kvar någon av tentorna kommer examineringen ske i två steg. Om du har C-tentan kvar skall du först göra inlämningsuppgift 1 (C) Du hittar kraven för uppgiften här. När du är klar (och har meddelat det) kommer du att kallas till en muntlig examination där du får relatera din kod till några av kursens mål. Om du har Java-tentan kvar så gör du på samma sätt, men det är inlämningsuppgift 3 (Java) du skall göra.
Vid redovisning kommer vi att gå igenom slumpvis valda mål som du måste kunna diskutera utifrån din lösning. Du skall klara av fem mål av upp till sju.
Q: Hur anmäler jag mig till kodprovet?
A: Det kommer en länk till anmälan i ett meddelande i Piazza. Detta meddelande skickas också vidare till din studentadress.
Q: Vilken grupp är jag med i?
A: Grupperna postas i Piazza och uppdateras löpande. Vi får uppgifter om registrerade studenter stötvis vid terminens början och det går därför knackigt ibland att bli instoppad i en grupp.
Q: Jag är inte med i någon grupp!
A: Maila huvudassistenten.
Q: Jag har inte något login i AU-portalen!
A: Maila huvudassistenten.
Q: Jag har inte tillgång till Piazza!
A: Maila huvudassistenten.
Q: Hur länge gäller delresultat på kursen som inte har rapporterats in i LADOK/UPPDOK?
A: Avklarade kodprovsfrågor gäller till nästa kurstillfälle. Vad gäller enskilda mål gör vi en fall-för-fall-bedömning. Om du saknar färre än 10 mål från föregående tillfälle får du normalt tillgodoräkna dig dina tagna mål nästa år (= starta med dem avklarade). Läs mer här
Q: Får man komma förbi er på rummet och fråga?
A: Ja!
Q: Räknas det som fusk att hjälpa en annan student som kört fast med programmeringen?
A: Att hjälpa någon som kört fast att komma vidare räknas inte som fusk. Vi uppmuntrar till samarbete och framförallt till diskussion kring hur man kan lösa ett problem. Att skriva någon annans kod åt dem är inte att hjälpa dem! Att dela sin lösning med någon annan (utöver vad som krävs av uppgifter i kursen) räknas som fusk! Att passivt dela sin lösning på GitHub (etc.) är inte förbjudet så länge som ingen plagierar den.
Q: Jag är borta under en labb! Vad gör jag?
A: Förutom de första 6 labbarna som startar upp kursen är labbar inte obligatoriska. Du skall gå på labbar för att redovisa. Initialt har vi planerat in ca 30 labbar, så om du missar någon spelar det ingen roll.
Q: Jag har en idé – vill ni höra den?
A: JA!
Q: Why are these course pages a mix in Swedish and English?
A: I am in the process of translating the material for this course from Swedish to English. The reason for this is to be able to have non-Swedish speaking TAs on this course. This transition will be gradual, meaning that these pages are sometimes in Swedish, sometimes in English and sometimes a funky mix.