Basiselementer i gruppeundervisningen

• Gruppeundervisningen starter onsdag 14. september.

• Oppgavene er stort sett hentet fra kursboken, men de vi skal l�se er samlet p� en egen oppgaveside. Mange synes det er enklere � forst� oppgavene om man leser naturlig tilh�rende tekst i boken f�rst.

• Man kan g� p� den gruppen man vil.

• I tillegg til � f� oppgavene godkjent p� en gruppe m� filene ogs� leveres elektronisk p� http://www.ifi.uio.no/~inf3330/upload innen utgangen av hver uke (fredag kl 16.00). Se "Innlevering av oppgaver" i reglene for gjennomf�ring av kurset.

• Dette skjer p� gruppetimen:
  • Studentene legger hele oppgavesettet som en sammenstiftet besvarelse p� et bord n�r de kommer inn i lokalet.
  • Gruppel�rer starter med � g� gjennom viktige punkter i hver oppgave som man b�r legge merke til i vurderingen. (Siden alle som m�ter er godt kjent med oppgavene, kan denne presentasjonen v�re kort og rett p� sak.)
  • Deretter henter to og to studenter to sett oppgaver (innlevert av andre) pluss evt. et sett med l�sningsforslag utarbeidet av kursledelsen. To og to studenter retter i samarbeid to sett med oppgaver. Det gis karakter (med begrunnelse) p� hver oppgave.
  • Gruppel�rer(e) er tilgjenglig for � svare p� sp�rsm�l og hjelpe til med rettingen.
  • Studentene som retter et oppgavesett er ansvarlig for � merke av "godkjent" p� en liste som gruppel�rer har med seg.

• Juks har blitt et tiltagende problem p� Ifi etter at mengden obligatoriske oppgaver har �kt i forbindelse med innf�ringen av Kvalitetsreformen. Juks er i INF3330/4330 definert som brudd p� retningslinjene dokumentert p� denne websiden og p� eksamensiden. Gruppel�rerne har en viktig oppgave i � avdekke slike brudd.

  H�yst sannsynlig vil det bli krav om � levere oppgavene i elektronisk form f�r man m�ter p� gruppe. Vi har lagt ned mye ressurser i et program som kan avdekke at to tilsynelatende forskjellige programmer stammer fra ett program (dvs. at et program er kopiert selv om variabelnavn, kommentarer, rekkef�lge p� statements etc. er forskjellig). Mer informasjon om eventuelle krav kommer senere.

• Hver student er ansvarlig for � ha en portef�lje (samling filer) med oppgaver som er registrert godkjent. N�r og hvordan man gj�r disse oppgavene er likegyldig, men for � f� dem godkjent for portef�ljen, m� man ha levert dem inn til evaluering p� en gruppe og f�tt dem godkjent der.

• Studentene som evaluerer en annens oppgave deler ut fire karaketer etter visse retningslinjer sammen med minst en setning begrunnelse for karakteren. En av karakterene "Fremragende" (A), "Bra" (B) og "Feil" (C) kvalifiserer for � la oppgaven inng� i oppgaveportef�ljen. Studenter som ikke har f�tt til en oppgave fullt ut (kanskje stoppet opp p� et punkt eller to) kan alts� m�te p� gruppene og f� oppgaven med i portef�ljen s�fremt programmets essensielle biter er skrevet inn og evt. manglende funksjonalitet er n�ye angitt med pseudo-kode.

• Noen krav:
  • De som retter en oppgave, skal sette fullt navn og brukernavn og/eller sin student-ID (gis p� f�rste gruppetime) p� besvarelsen.
  • Sett navn p� egen oppgave - ellers vil den neppe bli registrert!
  • Navngi filene slik det er spesifisert i oppgaven.
  • Hvis du har samarbeidet tett med andre slik at programmer blir nesten like, skal "samarbeidet med [navn]" skrives inn i toppen av filen. Hvis ikke, kan du risikere � bli utsatt for p�stander om kopiering - en type juks Ifi ser sv�rt alvorlig p�.

• Noen gode r�d:
  • Ha med to kopier av egen besvarelse - det er greit � ha noe � sammenligne med n�r en skal evaluere.
  • Ha med en utskrift av oppgavene s� dere ser presist hva som skal besvares.
  • Ha karakterveiledningen for h�nden.
  • Ha med fornuftig arbeid - det blir ofte en del pauser.
  • Husk at det ikke bare gjelder � lage "noe som virker"; koden skal v�re oversiktlig og pen og forsynt med kommentarer der det er n�dvendig. Legg vekt p� korte kommentarer om prinsipielle steg i scriptet og unng� kommentarer med lite informasjonsinnhold utover det som st�r i koden. Husk at godt valg av variabel navn etc. ofte resulterer i selvforklarende kode. Alle script uten grafiske brukergrensesnitt skal v�re forsynt med kj�re-eksempler som skal kopieres inn i programfilen, enten som kommentarer eller "multi-line strings". Det er utfordrende � skrive oversiktlig, vedlikeholdsvennlig og utvidbar kode! (Se f.eks. hva som kjennetegner beautiful software.)

• Hvis man f�r underkjent en oppgave og er uenig i vurderingen, kan man levere den inn til gruppel�rer sammen med en argumentasjon. Gruppel�rer foretar da den endelige vurderingen av oppgaven.

• Studentene oppfordres til � rapportere tiden de bruker p� � l�se oppgavene. Dette kan bli viktig input til diskusjon om arbeidsmengden i kurset og hvor mange oppgaver man kan forvente � f� l�st hver uke. Foreleser, gruppel�rere og evalueringsgruppen er interessert i � f� disse dataene!