Generell informasjon om kurset

Innledning

Formålet med dette dokumentet er å gi en samlet oversikt over evaluering, eksamen, og prosjektrapporten i kurset IN166 (gjelder for begge varianter). Dette bør leses nøye igjennom av studentene før man leverer prosjektrapporten, og eventuelt før man går opp til muntlig eksamen.

Følgende tema omtales:

2) Evaluering av IN166/A-rapporter, høsten 2000

3) Informasjon om eksamen i IN 166 / IN 166A, høsten 2000

4) Informasjon om IN166/A-rapporter, høsten 2000
- Introduksjon
- Felles prosjektrapport
- Innledning i rapporten
- Individuell rapport: prosessevaluering
- Diverse informasjon

5) Problemstilling
- Introduksjon om problemstillinger
- Eksempler på problemer og delproblemer

1) Informasjonsteknologi og samfunn: Mål

Målet med kurset er å gi informatikkstudenter en bakgrunn for å forstå samfunnsmessige aspekter ved bruk av informasjonsteknologi (IT), og gi dem et grunnlag for å oppdage og analysere dette. Gjennom kurset skal studentene få innsikti og erfaring fra prosjektarbeid slik at de blir bedre i stand til å delta i arbeid vedrørende utvikling, innføring og bruk av IT. Spesielt skal studentene bli i stand til å følge de lover og avtaler som regulerer informatikeres arbeid.

Læringsmålene for kurset uttrykker hva studentene skal kunne etter kurset.

Gjennom prosjektarbeidet skal de lære å:

• undersøke og analysere et eksempel på bruk av IT
• arbeide konstruktivt i en mindre arbeidsgruppe slik at de
• bidrar til etablering av hensiktsmessige arbeidsformer
• bidrar til konfliktløsning
• ivaretar egne interesser gjennom felles arbeid
• evaluere arbeidsprosessen og egen innsats
• skrive en rapport som dokumenterer resultatene av prosjektet

Studentene skal i tillegg kunne:

• redegjøre for, forstå innholdet i, og kunne anvende de viktigste norske lover og avtaler om utvikling, innføring og bruk av IT
• gi eksempler på og diskutere hvordan samfunnsmessige forhold spiller inn på utviklingen av teknologi
• diskutere hvordan innføring og bruk av IT påvirker arbeid, arbeidsliv og samfunnsliv
• forstå at det finnes forskjellige interesser og perspektiver knyttet til informatikeres arbeid.

For IN 166-studenter (5 vt) ventes vesentlig mer refleksjon i forhold til alle læringsmålene.

2) Evaluering av IN166/A-rapporter, høsten 2000

Det gis karakter på rapporten, og for de gruppene som ikke velges ut til muntlig eksamen (eller ber om å bli eksaminert), vil denne karakteren bli stående som hvert enkelt gruppemedlem sin karakter i kurset, muligens modifisert av den individuelle prosessevalueringen.

Eksamen varer ca. en time. Tone og/eller Knut er eksaminator, i tillegg er en ekstern sensor tilstede. Tone (evt. Knut) eksaminerer, men ofte er sensor også aktiv i utspørringen. Vi starter med en kort diskusjon om rapporten, før vi går over på å diskutere pensum. Eksamensspørsmålene blir omtrent de samme som er gitt i øvingsgruppenes diskusjonsoppgaver. Du kan lese hva vi venter du har lært i kurset i kursets læringsmål.

Eksamen gir anledning til individuell vurdering, og betyr at medlemmene i en og samme gruppe kan ende opp med forskjellige karakterer: spesielt kan noen justeres opp dersom de gjør en god eksamen (eller ned dersom eksamenen er dårlig). Det er anledning til å stryke enkeltmedlemmer i en gruppe under eksamen selv om gruppas rapport har en stå-karakter. Dersom en kandidat stryker under eksamen må vedkommende ta emnet om igjen (inkludert ny prosjektoppgave). Dersom gruppa stryker (på oppgaven), vil sensor i enkelte tilfeller kunne anbefale gruppa å jobbe videre med oppgaven og gå opp til fornyet eksamen etter at den reviderte rapporten er vurdert (dersom den får stå-karakter).
 
 Konkret vurderer vi følgende tre aspekter når vi vurderer prosjektrapportene:

1) Undersøkelsen (viktigst)

• problemformuleringen: presise, velbegrunnede problemer som lar seg besvare innenfor kursets ramme
• metode som passer til å besvare problemstillingen, begrunnelse for hvorfor andre metoder ikke ble valgt.
• konsekvenser av metodevalget for avgrensningen av oppgaven
• at analysen og konklusjonen kan belegges med data
• at dataene er relevante for de problemene som er blitt studert (for analyse og konklusjon)

2) Rapporteringen

• rapportens struktur og disposisjon: logisk og begrunnet kapitteloppdeling og -rekkefølge som tydeliggjør poengene. Lett å følge den røde tråden.
• god presentasjon av prosjektet: av metode, data, analyse og konklusjon. Skille mellom data, kilder og egne analyser. Ingen "synsing"
• språk: lettlest og velformulert. Ingen unødvendige gjentakelser. Det synes ikke at gruppas medlemmer har skrevet forskjellige deler av rapporten fordi den er holdt i samme skrivestil og det er god flyt og lite gjentak i teksten
• god bruk av referanser både som bakgrunn for eget arbeid, og for å styrke eller diskutere analyse og konklusjon. Ikke ukritisk bruk av referanser.

3) IT og samfunn

• er prosjektets tema relevant for forståelsen av emnet "IT og samfunn"? Dekker prosjektet både IT, samfunn og forholdet mellom dem?
• viser gruppa forståelse for betydningen av IT i samfunnet, for organisasjonen og for den enkelte bruker?

4) I tillegg kan karakteren justeres av

• Individuell prosessevaluering

Bruk de gode rapportene fra i fjor og i forfjor (markert på listene) for å få en ide om hvordan en god rapport skal se ut. De av rapportene som ikke er elektronisk tilgjengelige, finnes i biblioteket.
 
 

3) Informasjon om eksamen i IN 166 / IN 166A, høsten 2000

Kurset IN 166 / IN 166A benytter flere undervisningsformer: forelesninger, diskusjoner i øvingsgrupper, prosjektarbeid, og litteraturstudier. Prosjektarbeidet skal dokumenteres i en skriftlig rapport. I tillegg skal hver student skriftlig evaluere eget og andres arbeid i sitt prosjekt.

I utgangspunktet baseres karaktersettingen i kurset på en vurdering av rapportene fra prosjektarbeidet: alle medlemmer i en prosjektgruppe får samme karakter. I tillegg spiller den individuelle prosess-evalueringen inn og justerer karakteren for hvert gruppemedlem.

Vi velger ut ca. 10 grupper til muntlig eksaminasjon. Vi vil forsøke å finne fram til grupper som kan ha mulighet for forbedring og grupper der vi antar en individuell vurdering kan være av interesse. Dette betyr også at grupper som har skrevet gode rapporter kan bli trukket ut dersom vi tror de kan forbedre karakteren ytterligere på eksamen. Utvelgelsen vil være basert på en evaluering av den skriftlige grupperapporten (f.eks. veldig ujevne rapporter, rapporter på grensen til stryk) og på vurdering av gruppemedlemmenes egen evaluering (f.eks. grupper med veldig ujevn arbeidsinnsats eller samarbeidsproblemer). Dette innebærer at grupper med medlemmer som ikke har bidratt til gruppas arbeid vil kunne trekkes ut til eksaminasjon, og at vedkommende kan stå i fare for å stryke.

Den muntlige eksamen foregår gruppevis (hele prosjektgruppen er inne samtidig), men evalueringen er individuell. Det betyr at medlemmene i gruppa kan få forskjellige karakterer -- og av og til hender det at enkeltindivider ikke består eksamen. Karakteren som settes på den muntlige eksamen vil være den endelige karakteren for medlemmene i de prosjektgruppene som er oppe til eksamen.

Hvilke grupper som velges ut, kunngjøres et par dager før eksamen: så sent fordi vi må forsøke å lese både rapporter og individuelle prosessevalueringer før vi plukker ut gruppene. Eksamen foregår sannsynligvis i uke 49 og 50, muligens må vi ta uke 51 i bruk også. NB Fordi IN166/A-eksamen må koordineres med andre eksamener for hver enkelt gruppe og hvert enkelt gruppemedlem, kan det forekomme avvik fra denne planen, dvs. at eksamen for enkelte grupper må holdes enten noe tidligere eller senere for å ikke kollidere med andre eksamener.

Eksaminasjonen vil i hovedsak dreie seg om pensum, men vi vil også bruke litt tid på prosjektet og prosjektrapporten. Læringsmålene uttrykker hva studentene skal kunne etter kurset. De tre første målene dreier seg om prosjektarbeidet og brukes som kriterier under evalueringen av prosjektrapportene. De fire siste læringsmålene oppfylles i stor grad gjennom forelesninger, pensumlitteratur og øvingsoppgaver. Spørsmålene som stilles i øvingsoppgavene er gode kandidater til eksamensspørsmål. Deltakelse i diskusjonene i øvingsgruppene er derfor god eksamensøvelse. Forelesningene dekker delvis pensum, og vil trekke fram det foreleserne mener er viktigst for IN 166/A. Disse synspunktene, samt hvordan pensum/forelesninger kan brukes i prosjektene (og omvendt) vil også være tema på eksamen. Se også notat om evaluering og rapportskriving.

Alle prosjektgrupper kan be om å bli eksaminert, og må da gi tydelig beskjed når prosjektrapporten leveres. Vi vil forsøke å få til en eksamen på de oppsatte dagene for grupper som har meldt fra at de gjerne vil eksamineres, men som ikke er blant de 10 utvalgte gruppene (NB vi vil ikke sjekke om det er enighet i gruppa ved slike henvendelser, og vi vil derfor ta enhver henvendelse om eksamen som en gruppe-henvendelse). Vi antar at et ønske om eksamen ikke gjelder så mange grupper, og vi tror derfor det er mulig å holde planen om å avvikle alle eksamener konsentrert i løpet av uke 49 og 50 (evt. 51). Dersom mange ønsker å bli eksaminert, kan det hende at vi ikke klarer det, det avhenger også av tilgjengelige sensorer.

4) Informasjon om IN166/A-rapporter, høsten 2000

Introduksjon

Det skal leveres to rapporter i kurset: en grupperapport som beskriver prosjektarbeidet: data, analyse og resultater, og en individuell rapport som evaluerer prosjektarbeidet som arbeidsprosess.

Her følger noen tips for rapportskrivingen.

Felles prosjektrapport

Rapporten skal være på maks 40 sider. Det er intet poeng å skrive langt, tvert i mot er korte rapporter ofte mer poengterte og tydeligere i analyse og konklusjon. Men det må likevel en viss lengde til for å beskrive prosjektet. Merk at det ofte er vanskeligere å skrive kort enn langt.

Rapporter blir best om de er strukturert etter logikken i undersøkelsen, dvs. at det dere finner ut også syns i rapportens struktur. Her følger noen punkter som ofte bør være med og et forslag til rekkefølge. NB punktene er ikke forslag til kapittelinndeling: noen av punktene kan inngå i samme kapittel.

• Innledning: Problemformulering (se nedenfor)
• Presentasjon av tema og undersøkelsesenhet/organisasjon
• Undersøkelsesmetode med begrunnelse for valg av metode
• Presentasjon av datamaterialet (gi leseren et bilde av det dere har sett og hørt)
• Resultater og funn: Hva undersøkelsen viste, og
• Diskusjon av dette (f.eks. overraskelser og motsigelser, evt. bruk av teori og begreper fra litteraturen)
• Konklusjon: Gjenta problemstillingen for prosjektet og de viktigste resultatene.
• Praktiske konsekvenser for undersøkelsesenhetene/organisasjoner. Kan resultatene være relevante for andre? Hvilke nye spørsmål reises? Ble prosjektets problemstilling besvart?

Spesielt punktene Resultater og funn, og Diskusjon blir bedre framstilt om de struktureres f.eks. etter delproblemer eller funn i prosjektet (f.eks. hvis en brukergruppe mener systemet er dårlig og en annen brukergruppe elsker systemet kan dere presentere hvert av synene i et eget kapittel, der dere beskriver, analyserer, forklarer og diskuterer hvorfor brukergruppen mener det de mener).
 
 

Innledningen i rapporten

Innledningen skal presentere en problemstilling og kan gjerne inneholde følgende:

Max 1 side om:

• Temaet
• Problemstilling: hva dere vil finne ut av
• Hvorfor dette er en relevant problemstilling (hva har dette med IT og samfunn å gjøre? Hvorfor er det interessant?)
• Målgruppe: for hvem er oppgaven skrevet (og hva kreves av forkunnskaper)
• Begreper, teori, hva andre har funnet ut (bare det viktigste, bør utdypes i et senere kapittel som bakgrunn for deres
• undersøkelse)
• Forskningsdesign (i grove trekk: vi anbefaler at dere skriver et eget metodekapittel)
• Presentasjon av sammenhengen i oppgaven. Et avsnitt om hvert kapittel. Sammenhengen mellom og rekkefølgen av kapitlene sier noe om logikken i oppgaven.

Rapportene skrives ut og stiftes sammen av gruppa. Gruppelærer skaffer kartong til omslag. Dere skal levere gruppelærer 6 eksemplarer, i tillegg bør dere gi et eksemplar til bedriften / personene dere har undersøkt (kartong til dette får dere også av gruppelærer).
 
 

Individuell rapport: prosessevaluering

Det skal også rapporteres fra gjennomføringen av prosjektet, dvs. arbeidsprosessen. Denne rapporten leveres som en individuell prosess-evaluering, og bør være på ca. 5 sider.

Prosessbeskrivelsen skal i hovedsak inneholde en evaluering av eget arbeid i prosjektet:

• hvilken rolle hadde du i gruppa?
• DIN EGEN vurdering av DIN egen innsats:
• synes du at du har bidratt i prosjektarbeidet?
• er din arbeidsinnsats passe stor?
• hva er dine bidrag?
• spesielt vil det være nyttig å oppsummere håndtering av konflikter og uenigheter: redegjør kort for eventuelle konflikter og uenigheter, og hvordan de er blitt håndtert.
• hva har du lært om arbeidsformen prosjektarbeid (hva vil du gjøre og ikke gjøre neste gang?)?

Det betyr at du sannsynligvis også må si noe om:

• arbeidsdelingen (roller)
• oppgavefordelingen (oppgaver, ref. ansvarskart)
• tidsplan (ref. milepælplan)
• resultater fra observasjonen av gruppas arbeid og diskusjonen av denne (de endringene som ble foretatt og som er med i det reviderte prosjekforslaget)
• en kort beskrivelse av arbeidet og
• en vurdering av prosjektarbeidet som arbeidsform (hva har gruppa lært)

De individuelle prosessrapportene fra hver gruppe stiftes sammen og leveres gruppelærer som legger dem gruppevis i en mappe. Leveres i 5 eksemplarer. Disse rapportene trenger ikke kartongomslag.
 
 

Diverse informasjon

Det finnes et program for å formattere en rapport: startex. Dokumentasjon fins på en postscript fil.

Se forøvrig notat om evaluering og eksamen.
 
 

5) Problemstilling

Introduksjon om problemstillinger

Et tema er en avgrensning av verden eller noen aspekter som vi vil studere. F.eks. informasjonsflyt i Rima 500, konsulentfirmaers kontrakter, fordeler og ulemper ved regneark, eller pensjonsutbetalinger. En problemstilling som er egnet for studium i dette kurset er et spørsmål som:

• vi ønsker svar på, som
• kan besvares, og som
• ligger innenfor temaet.

Problemstillinen blir tydelig når vi formulerer den som "Det er et problem at ...", men det krever at vi kjenner til problemet på forhånd. Alternativer er spørsmål som begynner med "Hvorfor .." og "Hvordan ..", altså spørsmål som ikke kan besvares med ja eller nei. For å finne ut av problemstillingen, må vi ofte finne ut av deler av den av gangen. Delproblemer kan også gjerne formuleres som spørsmål.
 

Eksempler på problemer og delproblemer

Det er et problem at personalet i kassene i Rima 500 butikker ikke får kjennskap til endringer i varepriser.

• Hvilke virkninger har det for kundene, personalet, ledelsen?
• Hvorfor hindres denne informasjonsstrømmen?
• Hvordan kan den bedres?

Det er et problem at en kontrakt mellom konsulentfirmaet IT-Prof og kunden Lett&Lurt spesifiserer kostnader og betalingsbetingelser i minste detalj, men unnlater å spesifisere ytelsene som skal leveres og hvordan dette skal foregå med samme presisjon.

• Hvordan og hvorfor har denne type kontrakter oppstått?
• Hvilke konsekvenser fikk den for Lett&Lurt, IT-Prof og konsulentene som arbeidet med oppdraget?
• Hvilke endringer ønsker de samme gruppene?

En data-kyndig regnskapsmedarbeider vil at alle skal ta i bruk hans selvlagde regneark som gir helt presise regnskapstall hver dag. Her ligger to problemer:

1. Regnearket er et énbrukerverktøy som ikke lar seg distribuere på noen trygg måte til alle som har behov for disse tallene.
2. Regnskapsmedarbeiderne kan ikke forstå at dette skal være så vanskelig, og de synes at data-folkene er ukyndige, vrangvillige og late.

Ett av disse problemene kan være passende for et IN166/A-prosjekt. F.eks. 1) Hvordan tar data-avdelingen vare på den kunnskapen som ligger bak slike enbrukerverktøy ved videreutvikling eller utskifting av flerbrukersystemer? Blir de som er ivrige til å lage egne systemer trukket med i videreutviklingsprosjekter? Blir funksjonaliteten i enbrukersystemene brukt som deler av kravspesifikasjonen til nye systemer? Støtter edb-avdelingen utviklingen av en-bruker systemer? Hva er grunnene til det?

Det er et problem at ansatte i 3 videregående skoler ikke vet hvilke pensjonsrettigheter de har opparbeidet seg.

Hvilke kilder har de for å få rede på pensjonsregler og sine egne pensjonspoeng? Hvilke muligheter har de for å kontrollere pensjonspoengene og for å slutte seg til hvor stor pensjon de får ved ulike mulige pensjonsaldre? Hvilke forbedringer i presentasjonen av disse reglene og dataene kunne gjøres med teknologien? Hvilke slutninger om befolkningen generelt kan vi trekke av kunnskapsnivået på de tre skolene? Hvordan passer informasjonssystemet til arbeidet det brukes i?

Dette er et generelt spørsmål, som kan være inngangsspørsmål til studier i mange slags organisasjoner. Delproblemer vil være å finne ut hvordan arbeidet foregår, hvordan informasjonssystemet inngår i arbeidsoppgaver, om samme system brukes av mange forskjellige mennesker til forskjellige ting, og om det egner seg like godt til alle oppgavene. Hvorfor er systemet designet slik? Hvilke arbeidsoppgaver passer det best til? Fins det arbeidsoppgaver som blir hindret eller forsinket av at systemet må brukes? Hvordan?

Et problem bør være

• konkret
• nytt og delvis ukjent
• motiverende (studentene ønsker å lære noe om det)
• av interesse for andre parter
• operasjonaliserbart
• håndterbart innen kurset

For at det skal være mulig å finne ut noe om problemstillingen, må delproblemene omsettes til spørsmål slik at svarene gir oss informasjon (ved intervju eller spørreskjema) eller til spørsmål der vi direkte kan observere eller lese oss til svarene. Vi kaller denne omsettingen for operasjonalisering.

Spørsmålene 1) "Hvor mange pensjonspoeng har du tjent opp?", 2) "Hvor kan du lese det?" og 3) "Hvordan kan du kontrollere at poengene er riktige?" er en mulig operasjonalisering av et delproblem i tilfellet pensjonsrettigheter.

Et delproblem som "Hvor stort er behovet for Internett?" er vanskeligere å operasjonalisere. Hvordan måle størrelsen på et behov? Hvordan kan noen vite hvilke effekter bruk av Internett vil ha? Det er mange faktorer som vil spille inn; kostnader I form av tid og penger, gevinster i form av tidligere tilgjengelig informasjon og "bedre" kommunikasjon med andre. Slike effekter er svært vanskelige å måle i ettertid. Enda vanskeligere er det å forutsi mulige effekter. Dermed vil det bli vanskelig å finne behovet. En mulig operasjonalisering kunne være å spørre "Hvor mange penger er du villig til å bruke for Internett-tilknytning?" Men når de man spør vet like lite om mulige effekter som det vi gjør, så blir vi ikke spesielt mye klokere av å få rede på en pengesum.

For å få en idé om hvor omfattende problem som kan behandles i prosjektet, kan vi gå ut fra omfanget av de empiriske studiene som en prosjektgruppe kan rekke å gjennomføre i løpet av kurset. Som et holdepunkt kan en gruppe gjøre f.eks. ett av følgende med tilhørende lesing av dokumentasjon:

• 5 - 10 intervjuer à 1 - 2 timer
• 3 - 5 timer video-observasjon
• Lage og dele ut 50 - 200 spørreskjemaer og behandle svarene hvis vi antar at 50% svarer (NB: å lage gode spørreskjema er vanskelig)

Dermed kan vi neppe studere kontraktsinngåelse i dybden for alle kontraktene til et firma, eller spørre et representativt utvalg av befolkningen om de forstår pensjonspoengberegning.