Prosjekt i faget Webprogrammering med PHP

Prosjekt i faget Webprogrammering med PHP Laget av Svend Andreas Horgen, oktober 2009 I dette dokumentet finner du en problembeskrivelse med krav til et større nettsted. Du (din gruppe) skal skissere og lage en løsning basert på problembeskrivelsen. Det stilles noen minimumskrav til hva løsningen skal inneholde. Dere skal forholde dere til frister. Til slutt forklares kort hva som vurderes i prosjektet. Les hele dokumentet før dere begynner. Bakgrunn: Problembeskrivelse... 1 Krav til et nytt system... 2 Generelt... 3 Administrasjon... 3 Visning... 4 Arbeidsform... 5 Krav til standarder og teknologier... 5 Veiledning underveis... 5 Endelig innlevering... 5 Frister... 6 Vurdering... 6 Rettigheter og bruk av systemet i ettertid... 7 Vedlegg A koblingstabell LU og aktiviteter... 8 Vedlegg B hva kan studentene?... 9 Bakgrunn: Problembeskrivelse Lærere som underviser i høgere utdanning deler ut lærestoff og legger opp til læringsaktiviteter. Studentene må for eksempel gjøre en del obligatoriske aktiviteter. Teoristoff, bidrag i forum, undersøkelser, små tester, lenke til støttelitteratur og liknende er også viktige bidrag i læringen. Det er derimot ikke meningen at studentene skal jobbe seg slavisk gjennom alt utdelt materiale rått bare for å gjøre læreren glad. Hensikten er selvsagt ikke å gjøre alt, men å lære. Studenter lærer på forskjellige måter. Noen liker å lese, andre å se en videosnutt, noen å diskutere seg fram til ny lærdom, dele erfaringer med andre og liknende. Hva er det egentlig som styrer læringen? Hva er det som er forventet lært etter å ha tatt et fag? Et av de viktigste styringsinstrumentene for læring, er såkalte læringsutbytter (ofte kalt læringsmål). Læringsutbyttene beskriver hvilken kompetanse studentene er

forventet å inneha etter å ha jobbet med en modul eller et fag. Læringsutbyttene kommmuniserer også hva faget inneholder overfor andre institusjoner, næringslivet og potensielle studenter. Her er noen eksempler på læringsutbytter for modulen Tilstandsbevaring i faget Webprogrammering i PHP : Etter å ha jobbet med denne modulen skal du: 1. Kjenne til problematikken rundt det faktum at HTTP-protokollen er tilstandsløs (type: kompetanse) 2. Forstå hvordan cookies fungerer (type: kompetanse) 3. Forstå hvordan sessions fungerer (type: kompetanse) 4. Kunne bruke cookies for å bevare informasjon over tid (type: ferdighet) 5.... og så videre... Gode læringsutbyttebeskrivelser sier faktisk mye om hva som bør utvikles (eller videreutvikles) av læringsressurser og aktiviteter i et fag. I praksis er det mange lærere som ikke tenker aktivt nok igjennom læringsutbyttene de har formulert (en gang i tiden). Beskrivelsene kan i praksis ofte leve sitt eget liv i stedet for å faktisk styre undervisningen. Lærere vil for eksempel legge opp til lærestoff, tester, oppgaver og andre aktiviteter. En god lærer kan ikke gjøre dette helt tilfeldig, men må ta utgangspunkt i forventede læringsutbytter for faget. Det er ikke uvanlig at beskrivelsene er diffuse eller dårlig formulerte, og da har de liten verdi. Av alt dette aner vi at godt formulerte læringsutbytter blir en viktig forutsetning for god kvalitet på undervisningen. Læringsutbyttene formidles til studentene på lik linje med øvrig lærestoff og aktiviteter. Undersøkelser viser derimot at mange studenter ikke leser læringsutbyttebeskrivelsene. Det er ikke bare viktig å lese beskrivelsene, men også å forstå dem, reflektere over innholdet og kunne planlegge arbeidet sitt med utgangspunkt i dem. Etter fullført modul/tema bør studenten typisk sjekke om læringsutbyttene er oppnådd (for sin egen del). Læringsutbyttebeskrivelsene er altså et viktig redskap for studentene både for å vite hva en skal fokusere på, og for å bekrefte faglig ståsted. Læringsutbyttebeskrivelsene er veldig viktige for eksempel i forbindelse med sluttvurdering (eksamen), men også i underveisvurdering. Det må være samsvar mellom aktivitetene som kjøres i et fag og vurderingen. En konkret utfordring er at det ofte er tungvindt for læreren å lete opp alle læringsutbyttebeskrivelser når en skal planlegge fagets aktiviteter eller lage eksamensoppgaver. Midlertidig konklusjon: Læringsutbytter er sentrale i ethvert fag. Vi trenger økt fokus på læringsutbyttene både overfor studenter og lærere. Det er viktig å få oversikt over beskrivelsene på tvers av moduler, og det er behov for å tydeliggjøre hvilke aktiviteter som dekker de ulike læringsutbyttene. Krav til et nytt system Det er ønskelig med et webbasert system som håndterer læringsutbytter overfor læreren og studentene. Vi tenker oss et todelt system hvor den ene delen primært er

for lærerens administrasjon av læringsutbyttebeskrivelser. Den andre delen er for bruk av læringsutbyttene på forskjellige måter, og vil typisk vises til studentene. Her følger noen krav som ønskes implementert, men du står også fritt til å tenke kreativt og pragmatisk. De punkter som står markert med XTRA er ikke nødvendige å gjøre, men anbefales fordi de er faglig mer krevende (og dermed lærerike). Spesielt det å realisere tabellen som vist/forklart i vedlegg A, anbefales på det sterkeste. Generelt Verdt å merke seg om systemet: Websidene bør, som alle websider, være nogenlunde fine å se på og oversiktlige i navigasjonen. Legg likevel merke til at dette ikke teller mye i dette prosjektet. Innlogging er ikke noe tema. Vi antar at systemet er åpent for alle lærere, og at lærerne ikke ødelegger for hverandre. Det er altså ikke behov for noen innlogging. Sidene som omfatter administrasjon kan beskyttes helt enkelt med en.htaccess-fil om ønskelig i ettertid. Visse aspekter knyttet til sikkerhet må håndteres (feilsjekking, injisering etc). Lagring: Det er mulig å lage en mer eller mindre avansert underliggende lagringsstruktur. I dette faget forutsetter vi ikke noen dyp kunnskap om databaser/filer, men det er god trening å prøve å lage et så fleksibelt system som mulig. Tenk gjennom mulige fremtidige utvidelser. Det er lov å være kreativ. Administrasjon Lærere skal kunne: Registrere et nytt fag. Faget vil ha en fagkode og et fagnavn, for eksempel LV197D Webprogrammering i PHP. Registrere en ny modul (det AITeL i sin fjernundervisning kaller leksjon) i et valgt fag. For eksempel kan læreren lage modulen Tilstandsbevaring i faget LV197D Webprogrammering i PHP. Det vil variere hvor mange moduler et fag har. De fleste fag ved AITeL har 12 moduler (leksjoner), men noen har mindre enn 12 (typisk 3, 4 eller 6). Fleksibilitet er viktig. Registrere et nytt læringsutbytte for en modul. Et læringsutbytte består selvsagt av den tekstlige beskrivelsen, men er også av type kompetanse, ferdighet eller holdning. Eksempel: Forstå hvordan cookies fungerer. Type: Kompetanse. Et annet eksempel: Kunne bruke cookies for å bevare informasjon over tid. Type: Ferdighet. Det vil typisk være 3-6 læringsutbytter for hver modul, men det kan også være flere/færre. Se alle læringsutbytter (på en oversiktlig måte) i en, flere eller alle moduler i det valgte faget. XTRA (anbefales): Fylle ut en matrise/tabell som viser hvilke aktiviteter som brukes for å dekke opp de ulike læringsutbyttene i de ulike modulene. Se

vedlegg A sist i dette dokumentet for eksempel på hvordan en slik tabell kan se ut og mer utfyllende forklaring/kravliste. Realiser funksjonalitet som best mulig støtter opp under kravene i vedlegg A. Merk også at noen andre XTRApunkter bygger videre på denne funksjonaliteten. XTRA: Liste ut tabellen beskrevet i vedlegg A for alle moduler (ikke bare én modul). Slik kan læreren få bedre totaloversikt over hele faget sitt. XTRA: Lag et filter i tabellen i vedlegg A slik at kun læringsmål av en spesiell type listes ut, for eksempel kun de av type ferdighet. Dette forutsetter at alle moduler kan listes ut (bygger altså på forrige punkt). Dette gir mening fordi læreren da får se for eksempel alle læringsutbytter i alle moduler som er av type ferdighet og hvilke aktiviteter som brukes for disse. XTRA: Bytte om rekkefølgen på hvordan læringsutbyttene skal listes ut innenfor en modul (for eksempel at læringsutbytte nr 4: Kunne bruke cookies... kommer før læringsutbyttet om sessions). XTRA: Endre og slette læringsutbyttene. Visning Når læreren har lagt inn læringsutbytter for sine moduler i et fag, må studentene kunne se læringsutbyttene og kunne bruke disse i ulike sammenhenger. Det er et viktig poeng at studentene IKKE skal logge seg inn i noe eget system. Læreren ønsker typisk å vise læringsutbyttene i ulike sammenhenger, både i it s learning og på vanlige websider, og å sende slike til andre faglærere rundt om i landet, næringslivet og så videre. Læringsutbyttene er på ingen måte hemmelige, snarere tvert i mot! For at funksjonaliteten skal kunne aksesseres på en fleksibel måte, er det lurt å presentere selve læringsutbytteinformasjonen på en enkel måte, og bruke URL på en gjennomtenkt måte. Det er gitt eksempel på hvordan URL kan bygges opp i hvert av punktene som omfatter visning av læringsutbytter. Du velger selv om du vil ha samme php-script for all funksjonaliteten, eller om du vil lage mange ulike script. Vise læringsutbytter for ønsket modul. [URL: Bruk fagid og modulid som parameter i URL-en] Se alle læringsutbytter i faget. [URL: Bruk fagid som parameter i URL-en] Etter å ha gjort seg ferdig med en modul, skal studentene kunne fylle ut en liten spørreundersøkelse som lages automatisk. Se vedlegg B for utdypende informasjon. [URL: Bruk fagid og modulid som parameter i URL-en] XTRA: Kanskje er læringsutbyttet dårlig formulert? Det bør være mulig for studentene å gi en kommentar til de læringsutbytter de synes har diffus tekst, slik at læreren kan forbedre det. [URL: Bruk fagid og modulid som parameter i URL-en] XTRA: List ut tabellen beskrevet i vedlegg A, altså slik at studentene får se tabellen. [URL: Bruk fagid og modulid som parameter i URL-en] XTRA: Søk i læringsutbyttebeskrivelsene på tvers av fag. Dette er høyaktuelt for faglærere som lurer på om andre har overlappende lærestoff. [URL: Bruk

kun søkekriteriet som parameter i URL-en, evt. også avgrens til ønsket fagkode] Selv om du gir tilgang til websidene gjennom URL, er det mulig å gruppere dem sammen på en index-side eller liknende. Føl fri til å gjøre dette også, men ivareta behovet for at all funksjonalitet skal kunne nås via URL! Arbeidsform Anta at din prosjektgruppe er leid inn som konsulenter for å lage et dynamisk og interaktivt nettsted. Dere trenger ikke nødvendigvis å fylle nettstedet med innhold, men må ha dummy-bilder og dummy-tekst (ala Lorem Ipsum Dolor Sit Amet ) for å illustrere hvordan de endelige sidene vil komme til å se ut. Se http://www.lipsum.com/ for generering av slik tekst. Bruk gjerne reell tekst, men ikke bruk mye tid på teksten (Lorem Ipsum er tilstrekkelig). Det er mye mer viktig å få PHP-løsningen på plass opp mot underliggende database enn det er å få en flott utseendemessig nettside. Dere må selv lage de nødvendige databasetabeller. Det er opp til dere som konsulenter å bestemme hvilken løsning dere vil lage, gitt de kravene som er angitt i problembeskrivelsen og øvrig informasjon i dette dokumentet. Krav til standarder og teknologier Systemet skal basere seg på PHP. Det er likegyldig hvilken underliggende databasestruktur som velges, men MySQL er å foretrekke (siden det er det som brukes i faget). Det er ønskelig at webstandarder følges, blant annet bruk av XHTML. Bruk gjerne stilsett (CSS), men merk at utseendet ikke står i fokus i dette faget. Det er fritt fram for den som vil ta en ekstra utfordring og spe på med for eksempel Ajax i grensesnittet, men slikt gir ikke noe ekstra uttelling. Det stilles ikke krav til modellering av systemet utover det lille som står i avsnittet Endelig innlevering. Veiledning underveis Det gis i utgangspunktet ikke veiledning underveis i prosjektet, men ikke nøl med å spørre faglærer eller andre som tar faget om hjelp eller tips/råd gjerne i fagets forum (for da kan alle bidra med innspill og få del i de svar som gis). Det kan for eksempel være at oppgaven er vanskelig å forstå, at dere trenger råd i forbindelse med strategi for koding, tips til oppbygning av databasen og liknende. Endelig innlevering Det viktigste produktet er selvsagt selve nettstedet med all kode (det vil si alle filer som utgjør nettstedet). Ta med en dump av databasen med fornuftig innhold (ikke en tom database :-). Spør i forumet dersom du er i tvil om hvordan du tar dump av databasen.

Dere skal i tillegg til å lage et nettsted, også lage en liten sluttrapport på mellom 5 og 10 sider. Sluttrapporten skal inneholde: En forklaring (med skisse) av hvordan nettstedet er bygget opp og fungerer. Kort begrunnelse for valgt design, funksjonalitet og liknende. Kort beskrivelse av hvordan dere har jobbet og hva dere eventuelt ville gjort anderledes. Ta også med mulige fremtidige utvidelser. Ting i løsningen deres som dere vil fremheve som spesielt bra. Oppsummering over totalt tidsforbruk for hver enkelt deltaker og for gruppen som hele. Legg ved timelistene for den enkelte. Dere skal også levere en lenke til nettstedet. En på gruppen må legge ut nettstedet dere lager, for eksempel på adressen http://stud.aitel.hist.no/~brukernavn (der brukernavn tilhører en av dere på gruppen). Dere kan også bruke andre tjenere om dere har tilgang til det. Frister Endelig prosjektinnlevering (kode og sluttrapport): Fredag 4.desember 2009. Det er selvsagt lov å levere tidligere også. Dere får respons i form av godkjent/ikke godkjent samtidig med sensuren på eksamen. Vurdering Estimert arbeidsmengde med prosjektet er: 4 uker x 7,5 timer per uke. Dere skal være 3 per gruppe. Det er altså normert med totalt ca 90 timers arbeid ( + ) samlet for hele gruppen. Dersom dere er færre personer på gruppen, så må likevel arbeidsmengden tilsvare 90 timer (normert jobbing for 3 personer). Pensum i dette faget er definert utfra leksjoner, øvinger og liknende. Det er ikke noe krav om avansert forståelse for verken databaser eller systemutvikling. Prosjektet vurderes som bestått/ikke bestått. Følgende momenter blir tillagt vekt i forbindelse med vurderingen (produktet teller mest) Prosess og deltakelse som fremgår av sluttrapporten. Kvalitet på nettstedets funksjonalitet. Kvalitet på kode. Kreativitet i løsningen. Sluttrapportens innhold. Evne til selvstendig arbeid. I utgangspunktet får alle på gruppen samme vurdering, men individuell vurdering kan bli aktuelt dersom arbeidsinnsatsen internt i gruppen har vært veldig skjevt fordelt (det vil si at noen kan bestå mens andre får ikke bestått).

Rettigheter og bruk av systemet i ettertid HiST og BI og Høgskolen i Nord-Trøndelag (HiNT) har et prosjekt i 2009/2010 som går på nettopp dette med underveisvurdering, læringsutbytter og en hel del andre spennende tema. Prosjektet støttes av Norgesuniversitetet og heter ASSESS 2010. Den prosjektoppgaven som dere skal løse i PHP-faget, er tilknyttet arbeidet i ASSESS 2010. Dere er altså med på forskningsarbeidet ved HiST og får indirekte delta i forskningsprosjektet ASSESS 2010 ved å gjøre oppgaven. Dere blir blant annet bedre kjent med viktigheten av læringsutbytter. Det er mange studenter som tar dette faget, og noen grupper vil komme til å lage så gode systemer at de vil kunne gi stor nytteverdi både for lærere og studenter i det virkelige liv. Vi vil derfor gjerne få lov til å kunne benytte de beste systemene i vår praktiske undervisningssituasjon i tiden fremover. Dere kan altså gjennom PHP-prosjektet bidra med å forbedre læringen! Dersom vi ender opp med å bruke systemet din gruppe har utviklet, så vil dere selvsagt bli behørlig kreditert med navn i selve systemet og i evt. forskningsrapporter som skrives om temaet. Det kan være bugs i slike system. Hvis vi velger å bruke deres system, så er bugs vårt ansvar. Dere vil altså ikke bli belastet med noe etterarbeid knyttet til bug-fiksing og videreutvikling. Vi ved HiST/HiNT/BI må derimot få lov til å videreutvikle/tilpasse systemet etter eget ønske og fikse bugs selv. Dersom din gruppe ikke ønsker at HiST, BI og HiNT (og eventuelt andre institusjoner) skal få bruke systemet dere lager, så er det bare å si fra om dette. Dere bestemmer selv over det dere har laget selv om det er en skoleoppgave. Vi har stor respekt for opphavsrett. Det eneste dere i så fall må gjøre, er å si spesielt fra når dere leverer prosjektet at dere ikke ønsker at systemet skal brukes. Dere vil i så fall få bestått/ikke bestått helt på lik linje med alle andre. Reservasjon mot fremtidig bruk har med andre ord ingen innvirkning på vurderingen i dette faget, og dere skal ikke ha dårlig samvittighet om dere velger å si at vi ikke får lov til å bruke systemet dere lager. Dere trenger heller ikke begrunne dette valget nærmere det er nok å skrive at vi ønsker ikke at systemet skal brukes i ettertid når dere leverer inn prosjektarbeidet. Hvis noe er uklart rundt dette, så spør faglærer, gjerne i forumet så alle kan se.

Vedlegg A koblingstabell LU og aktiviteter Faget har ulike aktiviteter, men hva hører til de ulike læringsutbyttebeskrivelsene? Eksempel: Læringsutbytte nr 1 dekkes av en PDF-fil med teori, en test og forumaktivitet. Læringsutbytte nr 2 dekkes av en PDF og en undersøkelse. Læringsutbytte nr 3 dekkes av en PDF og en øving. Læringsutbytte nr 5 dekkes av en undersøkelse og en video. Det er ingenting som dekker læringsutbytte nr 4. Dersom alt dette er satt opp på tabellform vil læreren få god oversikt over sammenhengen totalt sett i modulen og også i hele faget sitt. Her er et eksempel på hvordan koblingen mellom læringsutbytter (forkortet LU) og ressurser/aktiviteter kan visualiseres. Helt til venstre er typen LU der K står for kompetanse, F for ferdighet og H for holdning. PDF Test Forum Undersøkelse Øving Video K LU 1 X X X K LU 2 X X K LU 3 X X F LU 4 H LU 5 X X Tabellen er tenkt å være til god hjelp for å gi læreren oversikt i sitt fag. Det er læreren som fyller ut X-ene i tabellen. LU 1 har beskrivelse: Kjenne til problematikken rundt det faktum at HTTP-protokollen er tilstandsløs. Studentene får en PDF med teori om HTTP og tilstandsløshet. I tillegg er det en test med noen spørsmål om hva tilstandsløs betyr og studentene oppfordres av læreren til å gi eksempler på tilstandsløse webløsninger i forumet. Derfor krysser læreren av at LU 1 dekkes av PDF, Test og Forum. Legg merke til at PDF-en, testen og forumet kan dekke mange læringsutbytter samtidig. PDF-en med teori om HTTP og tilstandsløshet har trolig også teori og eksempler på bruk av cookies og sessions. Derfor setter læreren kryss både for LU 2 og LU 3 på PDF. Læreren må altså krysse av for hvilke LU som dekkes av hvilke ressurser og aktiviteter. Merk også at når Test er avkrysset for LU 1, så sier vi ikke noe om hvilken Test som brukes, bare at det fins en test som går på det som læringsutbytte nr 1 dreier seg om. Læreren ser også fra tabellen sin at LU 4 ikke dekkes i det hele tatt. LU 4 sier: Kunne bruke cookies for å bevare informasjon over tid. Dette er en beskrivelse av type ferdighet. Her må læreren velge: a. Læreren ønsker kanskje å lage en ressurs/aktivitet som dekker LU 4. En øvingsoppgave kan være høyaktuell. b. Læreren ønsker ikke å dekke LU 4. Men: Da bør studentene bevisstgjøres på at dette er noe de må jobbe med på egenhånd. Det er altså fornuftig at læreren kan velge å vise denne tabellen til studentene for å tydeliggjøre!

Vedlegg B hva kan studentene? Bevisstgjøring av læringsutbyttene er viktig. Læreren kan lage en liten undersøkelse for å skape refleksjon og gjøre det lett for studentene å sjekke opp om læringsutbyttene er oppnådd. La oss først gjenoppfriske læringsutbyttebeskrivelsene som studentene har fått se i forkant av modulen: Etter å ha jobbet med denne modulen skal du: 1. Kjenne til problematikken rundt det faktum at HTTP-protokollen er tilstandsløs (type: kompetanse) 2. Forstå hvordan cookies fungerer (type: kompetanse) 3. Forstå hvordan sessions fungerer (type: kompetanse) 4. Kunne bruke cookies for å bevare informasjon over tid (type: ferdighet) 5.... og så videre... Det vil være veldig gunstig hvis læreren automatisk kan få laget en liten undersøkelse omkring disse læringsutbyttene (LU) på en egen webside, for eksempel en tabell (table-taggen) med radioknapper. Da kan studentene angi i hvilken grad de mener de har oppfylt hvert LU. En student skal kunne krysse ut og sende inn svaret sitt som illustrert i denne spørreundersøkelsen: Kan du med hånden på hjertet mene å...... kjenne til problematikken bla bla X Ja Delvis Nei... forstå hvordan cookies bla bla X... forstå hvordan sessions bla bla X... kunne bruke cookies bla bla X... og så videre bla bla X Etter å ha sendt svaret (trykke knappen Besvar ) skal studenten få en liten tilbakemelding automatisk, for eksempel etter følgende lest: Hvis bare Ja er utfylt, så vil tilbakemeldingen være: Flott, du behersker alt i denne modulen og er nå klar til å gå videre til neste modul. Hvis noen Delvis eller Nei er utfylt, så må tilbakemeldingen liste opp de læringsutbyttebeskrivelsene som en må jobbe mer med (Delvis krysset av) og mye mer med (Nei krysset av). Det aller beste er å få listet ut de aktuelle ressursene som dekker det aktuelle læringsmålet. Dette forutsetter derimot at den frivillige oppgaven som beskrevet i Vedlegg A er gjort. Ta det som en ekstra utfordring hvis dere har tid/lyst. MERK: Alt skjer anonymt og det er selvsagt ikke noen riktige svar. Hele poenget er å bli selvbevisst på hvor en står faglig, og sette seg nye mål som en jobber mot. Det er derfor ikke noe poeng i å lagre svarene.