Møte om evaluering av hovedprosjekt 5.juni 2003 OBS! Dette notatet er i sin nåværende form kun til internt bruk og ikke ment for studenter. Tilstede: Helge, Tomas, Svend Andreas, Walter, Mildrid, Jostein, Stein, Lene, Olav, Kjell, Per, Geir Ove, Else Dette notatet er ment å presentere mange av de synspunktene som kom fram på møtet. Det er imidlertid helt sikkert ting jeg har glemt. Takknemlig for tilbakemelding på det. (Årsaken til at notatet er på så mange sider, er at alle lysbildene som ble brukt i presentasjonen er tatt inn.) Trondheim, 6.juni 2003 Else Møteplan 1. Mål for møtet 2. Bokstavkarakter for alle prosjekter 3. Hva får studentene beskjed om? 4. Ulike studier, hva kan vi forvente? 5. Karaktersettingen 6. Problemprosjektene 7. Eksempelprosjekter en A/B-kandidat og en stryk-kandidat 8. Eventuelt Evaluering av hovedprosjekt - Våren 2003 2 Fokus er på det første av disse punktene. Imidlertid kan det også komme fram synspunkter som angår det andre punktet. Samler disse synspunktene her: Vi ble enige om et møte i januar neste år for på en bedre måte å samkjøre veiledningen av prosjektene. Det beste er om dette møtet kan holdes så tidlig at det kan ha innvirkning på retningslinjene for gjennomføring. Det må da holdes før orienteringsmøtet til studentene, det vil si tidlig i uke 2. Kanskje det er mulig å få det til før jul i stedet? Spesielt ble "oppstartmøtet" nevnt. Dette er det første møtet mellom studenter, oppdragsgiver og veileder. Det er mange viktige avgjørelser som tas der. 1
Dokumentasjon ble også nevnt. Sitat fra student: "Nye krav til dokumenter for hvert prosjekt." I retningslinjene er listen over dokumenter ikke satt opp som krav. Uttrykkene "Aktuell dokumentasjon" og "Ellers kan følgende være av interesse" er brukt. Å bestemme hva slags dokumentasjon som trengs i et bestemt prosjekt er et viktig punkt på oppstartmøtet. Sluttdokumentasjon er kun nevnt i fbm sluttrapporten slik: "I tillegg til rapporter som beskriver produktet (brukerveiledning, systemdokumentasjon, driftsdokumentasjon, etc.) skal gruppen lage en sluttrapport. Her er hovedpoenget å dokumentere prosessen som har ført til sluttproduktet." Dette bør nok utdypes. Informere studentene bedre om hva som forventes for de ulike karakterene, og om hvordan de skal tolke våre tilbakemeldinger. Bokstavkarakterer for alle prosjekter Tidligere: Ingeniør tallkarakter HK og ViD bestått/ikke bestått Nå: Bokstavene A-F for alle studenter: A: Fremragende prestasjon som klart utmerker seg. Viser stor grad av selvstendighet. B: Meget god prestasjon som ligger over gjennomsnittet. Viser evne til selvstendighet. C: Gjennomsnittlig prestasjon som er tilfredstillende på de fleste områder. D: Prestasjon under gjennomsnittet, med en del vesentlige mangler.. E: Prestasjon som tilfredsstiller minimumskravene, men heller ikke mer. F: Prestasjon som ikke tilfredsstiller minimumskravene Evaluering av hovedprosjekt - Våren 2003 4 Selvstendighet er kun nevnt under A og B. Det ble spurt om det var mulig med en fremragende prestasjon uten stor grad av selvstendighet. Ja, det er det. "Fremragende" går på det faglige nivået, mens selvstendighet gjerne omfatter andre elementer, som f.eks. initiativ og evne til på egen hånd å gjennomføre prosjektprosessen på en god måte. Hva får studentene beskjed om? Prosjektene evalueres med bokstavkarakter, A-E for bestått, F for ikke bestått. Det poengteres at det ikke er noen selvfølge at alle medlemmene i en gruppe får samme karakter. For å få bestått må kandidaten levere et resultat av prosjektarbeidet som viser at han eller hun er i stand til å fungere tilfredsstillende i et yrke som utdanningen kvalifiserer for. Prosjektet bedømmes på grunnlag av: kvaliteten på prosessen å arbeide med prosjekt kvaliteten på det utførte arbeid innleverte rapporter og dokumentasjon. Både innhold og språk er viktig. Dårlig språk er ofte til hinder for at leseren forstår innholdet. testkjøring / presentasjon av ferdig produkt tidsfrister overholdt I tillegg stilles følgende konkrete krav om timeføring, innlevering, etc.... Alle produkter vurderes opp mot de kravene som veileder (oppdragsgiver) og gruppe ble enige om tidlig i prosjektet. Det er viktig at veileder underveis i prosjektet danner seg et bilde av hvordan gruppen og den enkelte arbeider. Også sluttrapporten skal hjelpe til å bedømme hvordan gruppen har arbeidet underveis. Denne må derfor inneholde møtereferater, ukerapporter mm. som dokumenterer dette arbeidet. Det er også svært viktig at det går klart fram hvem i gruppen som har gjort hva. Dette er spesielt viktig ved eventuelle klager på sensuren av prosjektet. For prosjekt som inneholder system/programutvikling vil i tillegg følgende bli tillagt vekt: At vedtatte metoder og standarder for systemutvikling er fulgt. At brukergrensesnittet er "godt". At testkjøring av systemet ikke viser større funksjonelle mangler i forhold til spesifikasjonen. Gruppen kan gjerne på et tidlig tidspunkt bli enige med veilederen om hvordan dette punktet kan spesialtilpasses til det aktuelle prosjektet. Evaluering Evaluering av hovedprosjekt skjer - Våren så mot 2003 det en er blitt enige om. 5 2
Dette er hentet fra retningslinjene for gjennomføring. Merk at det også her refereres til oppstartmøtet. Nå er det imidlertid ikke enkelt å forutse alt på et oppstartmøte (spesielt ikke for en veileder som kanskje nettopp har fått prosjektbeskrivelsen, og som samtidig skal holde orden på opptil 8-10 forskjellige prosjekter...). Et moment fra oppstartmøtet er at man kan bli enige om å bruke (en eventuelt revidert utgave av ) følgende skjema: Evalueringskriterier hovedprosjekt Dette er ment som Generelle retninglinjer og må derfor tilpasses det enkelte prosjekt. Både med tanke på emner/delemner og vekting. Kriteriene gjennomgås med studentene tidlig i prosjektfasen. Emner Delemner Vekt Prosessen (gjennomføringen) Dokumentasjon Produkt (systemet) Prosjektside på www (oppdatering) Ryddighet når det gjelder planer og statusrapporter Møteinnkallinger og møtereferater Forholdet til oppdragsgiver/ kunde Forhold til veileder Evne til selvstendighet, initiativ Samarbeid - evne til å utnytte hver enkelts egenskaper og kompetanse Arbeidsinnsats (dokumentert) Ryddighet, struktur Språk, lesbarhet Innhold Egnethet (i forhold til oppgaven) Innlevering etter gitte krav (tittelside, zipfil, html fil, cd/ diskett...) Kvalitet, samsvar med behov Samsvar med dokumentasjon Omfang Originalitet, kreativitet i løsning Testkjøring/ presentasjon av ferdig produkt 30% 30% 35% Presentasjon av prosjektet Innhold 5% Utførelse I tillegg vil ulike omstendigheter kunne påvirke gjennomføringen av prosjektet, som f.eks vanskelige oppdragsgivere, endringer av rammebetingelser/ forutsetninger rundt etc. Dette må nødvendigvis gi utslag i evalueringa f.eks ved å endre vektinga av de ulike emnene. (Slike omstendigheter bør gå fram av prosjektdokumentasjonen.) 2001-05-11 Greta og Grethe Underveis i møtet ble det nevnt flere momenter vi bør ta hensyn til. De aller fleste (alle?) står i dette skjemaet, om enn med en noe annen ordlyd. Forholdet til oppdragsgiver/kunde kan utdypes med forståelse av oppdragsgivers krav. NTNU sin "Anbefaling ved sensurering i bokstavkarakter-skala" ble delt ut på møtet for å vise hvilke momenter de vektlegger ved vurdering av hovedoppgaver o.l. Der gjelder følgende anbefalte vektlegging: Problemforståelse 0-25% Bakgrunnsutredning 0-10% 3
Problemutredning 0-25% Eget bidrag/selvstendighet 0-10% Diskusjon/kritikk 0-20% Litteraturhenvisning/ rapportkvalitet 0-10% 0-100% Dette kun til orientering. Vi observerer blant annet at prosessen ikke er nevnt i det hele tatt, iallfall ikke direkte. Ulike studier, ulike krav? Selvstendighet og initiativ Skriftlig uttrykksevne Problemforståelse evnen til å formulere/utdype problemet Teknologisk forståelse hvilken teknologi skal jeg bruke? Evaluering av hovedprosjekt - Våren 2003 6 Studentene fra de ulike studiene våre har ulike forutsetninger for å gjennomføre et hovedprosjekt. Av momentene over antas det at kravene til "Skriftlig uttrykksevne" bør kunne være det samme for alle studentene. "Selvstendighet og initiativ" antas å være omtrent proporsjonalt med antall år studenten har studert, og vi bør dermed kunne kreve mest av ING- og ViD-studenter, og noe mindre av HKstudentene. De to siste punktene vil i stor grad være proporsjonalt med hvor lenge studentene har studert teknologi/it. Her stiller ViD-studenter med ikke-teknologisk bakgrunn (f.eks. lærer, sykepleier) absolutt svakest, mens ViD-studenter med teknologisk bakgrunn (f.eks. elektroingeniører) og INGstudenter antas å ha best bakgrunn. I tillegg bør vi ta hensyn til følgende momenter: Hvorvidt studenten er FU-student eller ordinær student. Underforstått: Det er kanskje vanskeligere å være FU-student enn ordinær student? Ja, kanskje for de som sitter alene hjemme og studerer, men neppe for de som gjør prosjektet i tilknytning til egen arbeidsplass. Om han/hun jobber alene eller i gruppe. Underforstått: Det er kanskje vanskeligere å jobbe alene enn i gruppe? Helt sikkert ikke for alle. Disse to momentene er uavhengig av typen studium. 4
Studiene Ingeniør 2,5 års teknologisk utdanning før prosjektstart, erfaring gjennom flere lignende prosjekter Høgskolekandidat 1,5 års teknologisk utdanning, kun erfaring fra ett mindre systemutviklingsprosjekt ViD kan ha så lite som 0,5 års teknologisk utdanning, behøver ikke ha noen erfaring fra teknologiprosjekter Evaluering av hovedprosjekt - Våren 2003 7 Det ble påpekt at HK- og ING har omtrent like mange studiepoeng IT-relaterte fag. Kan vi ikke da forvente omtrent det samme av disse to gruppene? Sannsynligvis kan vi ikke det. Det er flere årsaker til det. ING-studentene har ett år ekstra modning flere prosjekter som direkte bygger opp under hovedprosjektet flere matematisk relaterte fag som skal hjelpe dem til å oppøve analytisk tankegang og evnen til problemløsning HK-studentene har kun ett prosjekt der de lager en Access-database. Selv om de færreste lager databaser i hovedprosjektet, har de likevel fått grunnleggende kunnskaper om prosjektgjennomføring og har også fått erfaring med rapportskriving. Konkret lager de i dette faget oppstartdokument, brukerkravdokument, systemkravdokument, brukerveiledning og sluttrapport. ViD-studentene er en meget sammensatt gruppe, og veileder bør ta i betraktning bakgrunnen til studentene. Det bør forventes mer på teknologisiden av en ViD-student med elektrobakgrunn enn en med sykepleierbakgrunn. Et problem er at relativt få utfører oppgaver av den typen det var meningen at de skulle utføre, nemlig oppgaver der de anvender IT i tilknytning til sitt opprinnelige fagområde. Så kommer utdrag av fagbeskrivelsen for de ulike studiene, samt litt om typen oppgaver de fleste studentene utfører: 5
Fagbeskrivelse - Ingeniør Oppgaven skal gi studenten øvelse i å løse en oppgave innenfor en gitt tidsramme. Den skal gi innsikt i, og gjøre bruk av ny/moderne teknologi, maskinvare, grunnprogramvare, databasesystem, applikasjonsverktøy o.l. Videre skal dette være en øvelse i å følge standarder i dokumentasjon, gjennomføring og kvalitetssikring av programvare.... utviklingsoppgaver, ny teknologi, vanligvis mye programmering Evaluering av hovedprosjekt - Våren 2003 8 Fagbeskrivelse - ViD Studenten skal bruke og utdype de kunnskaper som erverves i VID-studiet, innenfor det fagfelt eller den profesjon som han/hun er utdannet i tidligere eller vil arbeide innenfor. Prosjektoppgaven kan med fordel velges innen et område som studenten kjenner fra før eller er spesielt interessert i. Den må omfatte problemstillinger der det er særlig aktuelt å bruke kunnskaper fra VID-studiet. Oppgaven skal gi øvelse i å løse en realistisk datateknisk oppgave som brukeren har behov for innenfor en fastlagt tidsramme. Innsikt i ny teknologi, maskinvare, programvare o.l.... Få har oppgaver som passer med denne beskrivelsen. Evaluering av hovedprosjekt - Våren 2003 10 6
Karaktersettingen Et prosjekt til A skal klart utmerke seg. Totalt ca 90 prosjekter. 10-20 får A? Innhent synspunkter fra oppdragsgiver (medsensor). Enhver oppgave skal i utgangspunktet kunne besvares med et prosjekt til A, eller? Studentens selvstendige problemfordypning (forstudium, kravspek.) vil bestemme om dette kan bli A. Både A og B stiller krav til selvstendighet. Ingen veileder bør derfor føle at de har gitt for dårlig veiledning og av den grunn gi B (eller A!). Veileders tilbakemeldinger om ok, betyr ikke at det er A. Det behøver ikke bety mer enn C ( gjennomsnittlig prestasjon ). At alt som er beskrevet i kravspek. er implementert, betyr ikke at produktet er A. Husk at E en er smal: Prestasjon som tilfredsstiller minimumskravene, men heller ikke mer. Hvis det er noe mer, skal det gis D. Skjemaet som en del bruker Erfaringer? Kan vi anta at en må stå på hver enkelt av de tre hoveddelene for at det skal bli ståkarakter totalt, selv om det ikke står eksplisitt? Medsensor. Stort fag. En fordel at to personer ser på prosjektet, spesielt hvis i toppen eller bunnen av skalaen. Ofte fungerer oppgavestiller godt som medsensor. Bør uansett hente inn synspunkter fra denne. Oppgavestiller uten teknisk innsikt, eller ikke aktuell av andre grunner: Lektorer bytter prosjekter internt. Evaluering av hovedprosjekt - Våren 2003 11 Flere ingeniørprosjekter er bedømt med bokstavkarakterer det siste året. Følgende liste ble lagt fram: A B C D E F Sum Prog.prosjekt 1ING 4 11,5 3 1,5 20 Syst.utv.prosjekt 2ING 2 7 10 1 20 Prosjekt, 3DSU 9 5 1 15 Prosjekt, 3DDT 3 6 1 1 12 Tallene vise antall prosjekter/grupper som fikk de ulike karakterene. (Årsaken til 0,5 B og 0,5 D for 1ING: En gruppe bestod av en faglig svak og en faglig sterk del. Dette var det åpenhet om helt i fra begynnelsen, og alle var inneforstått med at de to delene av gruppen fikk forskjellig karakter. Det ble også tatt hensyn til dette underveis, slik at den faglig svake delen av gruppen fikk enklere oppgaver som passet til deres nivå.) Det var vel enighet på møtet om at vi for hovedprosjektene forventer en fordeling omtrent som for programmeringsprosjektet i 1ING. Spørsmålet "Enhver oppgave skal i utgangspunktet kunne besvares med et prosjekt til A, eller?" ble satt opp, da det har vært hevdet av enkelte at det eksisterer oppgaver som er så trivielle at det ikke er mulig å få A på dem. Forsamlingen var vel i hovedsak uenig i dette. Alle oppgaver som godkjennes av avdelingen må kunne besvares med et A-prosjekt. De fleste oppgaver har imidlertid både enklere og mer avanserte løsninger. Det stilles krav til at studenten i sin egen formulering av problemet (forstudium, kravspesifikasjon) er såpass ambisiøs at prosjektet blir tilstrekkelig krevende. ("Studentens selvstendige problemfordypning (forstudium, kravspek.) vil bestemme om dette kan bli A.") "Veileders tilbakemeldinger om ok, betyr ikke at det er A. Det behøver ikke bety mer enn C ( gjennomsnittlig prestasjon )." Dette var det vel enighet om. Ja, kanskje det bare betyr D eller E? Dette er vi som veiledere klar over, men hva med studentene? Tror de det betyr A? "Jamen, du sa jo det var OK?" 7
Angående skjemaet som er gjengitt tidligere: Kun to av de frammøtte brukte dette aktivt i dette semesteret. Det kan skyldes at det er lite kjent at det eksisterer (det ligger lenke fra retningslinjene på fagets hjemmeside). Det ble ingen entydig konklusjon på hvorvidt vi skal kreve at man må ha ståkarakter på hver enkelt av de tre hoveddelene (prosess, dokumentasjon, produkt) for at prosjektet som helhet skal kunne bestås. Det ble ikke diskutert hvor mange poeng de ulike karaktertrinnene svarer til. Medsensor. Det ble poengtert at veiledere som er usikre, må kunne rådføre seg med kollegaer, men at vi ikke lager noe byråkratisk system ut av dette. Et spørsmål som ikke fikk noe entydig svar: "Er det et pluss eller et minus at studentene jobber mange flere timer enn de skal?" Problemstillingen der studenter innen samme gruppe får forskjellig karakter, ble drøftet. Eksempler fra årets prosjekter: Svend Andreas: En gruppe på tre mister en student. De andre gjør en ekstra innsats på grunn av dette. Studenten som forsvinner stryker, men de to andre bør få ekstra pluss for innsatsen sin. Tomas: I en gruppe på to gjør den ene svært liten innsats i forhold til den andre. Veileder er bestemt på å gi de to forskjellig karakterer. Problemprosjekt Dårlig formulert oppgave lage hjemmeside for xxxx tilleggskrav om interaktivitet for at oppgaven skal bli godkjent Student jobber alene skaffer / finner på prosjektet selv lite selvstendig ikke forutsetninger for å gjøre teknologi-valg Oppdragsgiver, hvis den eksisterer lite interessert liten teknologisk innsikt blir imponert av en webside med klikkbare lenker Evaluering av hovedprosjekt - Våren 2003 12 Dette gjelder ikke mange prosjekt, men det krever ofte uforholdsmessig mye innsats av veileder. Studentene kan være svært masete. 8
Hjelp til problemprosjekt En håndfull prosjekter. Men kan også hjelpe de andre til å gjøre bedre web-prosjekter. HKI: Faget Web-teknikker danner basis for å kunne gjennomføre et webprosjekt Dette faget går parallelt med hovedprosjektet Kan det flyttes til høstsemesteret allerede fra kommende studieår? Kan f.eks. bytte plass med Drift av lokalnettverk HKD PPI i 1.studieår. Deretter ingen webfag (med unntak av bonusfag) ViD Ordinær studieprogresjon gir PPI i vårsemesteret Bør velge valgfag i samråd med teknologi valgt for hovedprosjektet Skjev belastning, slik at faget kommer først og prosjektet etterpå. Lage notat ang. valg av teknologi (php, asp, jsp, database, verktøy) med litteraturanbefalinger (og ev. leksjoner) for den teknologien de velger. Evaluering av hovedprosjekt - Våren 2003 13 HKI: Geir Ove skulle se om det var mulig å flytte faget Web-teknikker til høstsemesteret allerede fra kommende studieår. HKD: Jeg må gjøre studentene oppmerksomme på at de sannsynligvis må sette seg inn i teknologi som de ikke har hatt i studiet, dersom de velger denne typen oppgaver. Kan gi anbefaling om bonusfag som de i tilfelle bør ta, dersom de har rett til det. ViD: De som velger web-prosjekt, må anbefales å velge valgfag som passer med den teknologien de skal bruke. Notatet som skal lages, må henvende seg direkte til studenten i den situasjonen vedkommende er. Snakket litt med Per om det i lunsjen, han var åpen for at temaet kunne være en leksjon i faget Webteknikker. Case ViD-prosjekt som strøk i fjor interaktivitet lite, og praktisk talt identisk med øvinger i webteknikker ingen rapporter på mer enn én side dårlig prosess (se beskrivelse fra veileder) HKI-prosjekt til A eller B? Evaluering av hovedprosjekt - Våren 2003 14 9
Case 1 Dette prosjektet fikk vurderingen "Ikke bestått" i fjor. Studenten påklaget vedtaket. Klagenemden opprettholdt vedtaket. I tillegg til veileder er prosjektet totalt vurdert av fire sensorer. Det virket også som om forsamlingen på møtet i går var enige om at dette ikke holdt mål. Oppgavetekst: Arbeidstittel: Hjemmeside for Dypvåg I.F. --------------------------------------------------------------------------- Hensikt: Lage en brukervennlig hjemmeside for idrettslaget der medlemmer kan finne ut om treningstider, stevner etc. Det blir også mulighet for "online" påmelding Beskrivelse: Lage en dynamisk hjemmeside som kommuniserer med serveren på forskjellig vis --------------------------------------------------------------------------- Stiller arbeidsplass: Ja Trenger arbeidsplass hos oss med: Begrensninger: Antall Studenter: 1 av type 4 i (1=ing,2=hkd,3=hki,4=vid,5=vet ikke) Antall dager: 18 Eventuelle studenter bestemt for oppgaven: XXXXXX ---------------------------------------------------------------------------- Oppgavestiller: Dypvåg I.F. Adresse: ----------------------------------------------------------------------------- Kontaktperson: Tlf: Fax: E-mail: ----------------------------------------------------------------------------- Utfyllende beskrivelse: Oppdragsgiver og student er den samme ------------------------------------------------------------ Prosjektet finner du på k:\data\kursdok\hovedpro\2002-2003\evaluering\oppgave.zip Interaktivteten som er praktisk talt lik øvingsoppgaver fra faget web-teknikker, er som følger: Et Javascript som beregner pris for sko (se filen GodeTilbud.html). Ingenting skjer på tjenersiden her. For å endre prisen må man endre scriptet. Perl-script som tar inn påmeldingene og legger dem på en tekstfil. Rapportene finner du også på denne katalogen. Av hensyn til studentens anonymitet har jeg utelatt ukerapportene og timelistene. Her er imidlertid veileders beskrivelse av prosessen: BEGRUNNELSE Selv om dokumentasjonen nå er ihht det som er utviklet, har han fått usedvanlig lite ut av oppgaven og brukt uvanlig lang tid på alt han har gjort. F.eks brukte han hele 8 timer på å lese gjennom fagets webside og 30 timer på prosjektplanen... PROSESSEN Han startet opp rimelig greit og han fikk kjøre sitt eget rapporteringsløp fordi han jobber i Nordsjøen. Jeg merket at han trengte mye tid på å lese om faget og å lage prosjektplan, men jeg kommenterte ikke det. Noen har problemer med det prosjektadministrative. I starten på mars fikk jeg en del dokumenter, blant annet kravspesifikasjonen som jeg hadde en del kommentarer til. Da reiste han ut i Nordsjøen igjen og det neste jeg fikk av han ca 4 uker senere (3. april) var en delvis realisert side. Da ante jeg ugler i mosen og tok kontakt med Else Lervik. Jeg tok også telefonkontakt med XXX og prøvde å få han til å få noe mer ut av oppgaven, men da viste det seg også at han faktisk ikke hadde en reell kunde slik at f.eks markedsundersøkelser av hva idrettslagets medlemmer kunne tenke seg på en hjemme side ikke var mulig å gjennomføre. 10
Den 23.april fikk jeg all dokumentasjon og en ferdig side. Det var ikke samsvar mellom dokumentene og heller ikke mellom dokumenter og realiseringen. Dtte rettet han opp etter at det ble kommentert. Jeg er ingen ekspert på å lage hjemmesider, men det han har prestert på 263 timer burde det være mulig å gjøre på mindre enn to ukeverk. Denne ble laget til klagenemden i forbindelse med at studenten påklaget vedtaket om "Ikke bestått". Case 2 Dette er et HKI-prosjekt som ligger i grenselandet A/B. Oppgavetekst: Arbeidstittel: Intranettløsning for institutt for bioingeniør- og radiografutdanning (IBR) --------------------------------------------------------------------------- Hensikt: Se utfyllende kommentarer Beskrivelse: Del 1: Utarbeide en intranettløsning for instituttets fellesinformasjon slik at informasjonen blir enklere å finne, samt at det blir lett å legge ut nye ting. Del 2: Inkludere institutthåndboka i intranettløsningen Del 3: Lage struktur for fagsider til studenter og lage et opplegg som gjør at hver enkelt faglærer kan legge ut sine ting på sine sider. Det må også lages en bruksanvisning som hver faglærer kan bruke for å administrere sitt område --------------------------------------------------------------------------- Stiller arbeidsplass: Nei Trenger arbeidsplass hos oss med: Begrensninger: Antall Studenter: 1 av type 3 i (1=ing,2=hkd,3=hki,4=vid,5=vet ikke) Antall dager: Eventuelle studenter bestemt for oppgaven: ---------------------------------------------------------------------------- Oppgavestiller: HiST Avd. for teknologi, IBR Adresse: Håkon Jarls gate 12 7004 Trondheim ----------------------------------------------------------------------------- Kontaktperson: Øystein Olsen Tlf: 73 59 75 24 Fax 73 59 75 11 E-mail oystein.olsen@ibr.hist.no ----------------------------------------------------------------------------- Utfyllende beskrivelse: IBR benytter i dag et fellesområde på serveren for å dele informasjon. Brukergrensesnittet er ofte Windows NT Explorer. I tillegg til alle fellesdokumenter og referater utarbeider instituttet en institutthåndbok som også legges på dette området. Noen av de ansatte ønsker å legge ut materiale i forbindelse med undervisningen på internett (passordbeskyttet). IBR ønsker å effektivisere informasjonsflyten mellom medarbeiderene (og studentene) og vil derfor ha et web-grensesnitt mot den interne infoen. I dag ligger denne informasjonen stort sett lagret i Word- og Excelfiler. Svend Andreas har laget en presentasjon av prosjektet. Den ligger på :\data\kursdok\hovedpro\2002-2003\evaluering\thoringe.ppt. Oppgaven har nr 25 og vil i sin helhet finnes på felleskatalogen for hovedprosjekter (k:\data\kursdok\hovedpro\2002-2003\innleverteprosjekter) etter sensurering. 11