Ved innføring av et nytt tema i en læringsprosess er en av utfordringene å finne oppgaver og demonstrasjoner som er egnet til å øke innsikten og å fremme motivasjonen. Dette er selvsagt en helt generell problemstilling og i de fleste tradisjonelle skolefagene har pedagoger og lærebokforfattere lang erfaring i hva som virker og under vilke betingelser. Det er en løpene debatt om dette innen de fleste fag. En debatt basert på læringsteorier og personlig erfaring.
Når jeg tar opp denne i og for seg trivielle problemstillingen her er det fordi programmering som fag kanskje reiser noen litt spesielle problemstillinger. Vi har relativt lite erfaring med programmeringsundervisning i skoleverket, fra barneskole til videregående. Jeg innrømmer gjerne at jeg også på høgskolenivå har bommet gjentatte ganger, spesielt i innføringskurs.
I dette innlegget vil jeg ta opp noen utfordringer knyttet til det "å finne rimelige oppgaver" i programmeringsundervisningen. Jeg vil først forsøke og fomulere noen premisser som i hvert fall for meg er viktige. Deretter vil jeg se litt på oppgaver som ble brukt i prosjektet ProgPed der temaet er programmering som pedagogiske verktøy i matematikkundervisningen i skolen.
Noen generelle betraktninger
- Programmering er på den ene siden et fag som stiller store krav til kreativitet, samtidig som det stiller absolutte krav til presisjon. Vi har stor handlefrihet i hvordan vi formulerer oss i forhold til de som skal bruke det vi lager (tekst, bilder, sidelayout, dynamikk), og stor grad også i hvordan vi formulerer regneregler (algoritmer). Men når vi først har bestemt oss kreves det en absolutt presisjon i beskrivelsen (syntaks). Konflikten mellom evnen og lysten til å skape på den ene siden og evnen til å implementere på den andre siden er en utfordring for mange. Spesielt fordi elevene til daglig ser og bruker programmer som det er lagt ned store ressurser og erfaringer i å framstille, enten det er spill eller andre anvendelser.
- Vi må forholde oss til en blanding av noen grunnleggende stabile prinsipper, samtidig som anvendelsesmulighetene og løsningen endrer seg svært raskt. De vanlige programmeringsspråkene har endret seg forbløffende lite, men anvendelsene av dem og konsekvensene er totalt annerledes enn for noen tiår tilbake. Det er verken mulig eller riktig å overse det siste perspektivet, selv i grunnleggende programmering. Elevene kjenner deler av denne virkeligheten godt og har forventninger og kanskje noen betenkligheter. (Hvis de ikke har noen betenkligheter bør de kanskje oppfordres til å tenke litt på det.)
- Programmering forutsetter et omfattende begrepsapparat (variable, lister, objekter, funksjoner, datatyper, logiske tester, løkker). De som er trent i faget bruker ikke disse begrepene bare for å beskrive noe, men de brukes til "å tenke med". Erfaringsmessig er ikke alle disse begrepene trivielle i en innføringsfase. En av de store utfordringen i å lage rimelig oppgaver blir å finne enn motivert progresjon i forståelsen av begreper.
- Programmer skal gjøre noe. Vi må med andre ord velge en anvendelse. Denne anvendelsen bør oppfattes som meningsfull i en eller annen kontekst. Denne konteksten kan være hentet eksplisitt fra pensum i et annet skolefag eller fra en eller annen dagligdags situasjon. I eksempelet som følger er det matematikk som er konteksten. Veien fram til det som oppfattes som løsningn må tilpasses elevgruppa, og må spesielt i starten ikke være for lang.
- Oppgavene må ha en rimelig progresjon. Denne progresjonen må kombinere ambisjonsnivået på selve løsningen og ambisjonsnivået i begrepsforståelsen. Det ideelle er at vi greier å få disse til å forsterke hverandre. Nye begreper forenkler ofte koden vår, øker handlingsrommet og tillater større kreativitetet i problemløsningen. Vi må altså være veldig oppmerksomme på mestringsgraden.
I eksempelet nedenfor har ikke alle disse vurderingen blitt tillagt like mye vekt, men noen av dem ligger eksplisitt til grunn.
Et prosjekt
Det aktuelle prosjektet er knyttet til matematikkundervinsing i ungdomsskolen, 9.trinn. Tema var beregning av flater og volum. Rammene for prosjektet var 3 økter på tilsammen 8 timer. Elevgruppa var 24 elever som i hovedsak arbeidet to på en maskin. To matematikklærere var med, men instruksjoner og veiledning ble gitt av bachelorstudenter fra Høgskolen i Østfold. En detaljert beskrivelse av prosjektet er gitt i studentenes bacheloroppgave
Programmeringsomgivelsene som ble valgt var Processing. Oppgavene og programmeringsomgivelsene var demonstrert og drøftet med lærerne i forberedelsene av prosjektet. Processing ble valgt fordi det er enkelt å kontrollere grafisk output og fordi det er mulig å ha en progresjon i begrepsbruken som kan tilpasses oppgavene, i hvert fall innen rammene for det temaet som var aktuelt i dette tilfellet.
Introduksjon
Processing ble introdusert i en sesjon der elevene arbeidet paralellt med instruktøren som forklarte på storskjerm. Det viste seg å gå greitt å introdusere de helt nødvendige begrepene som variable (float), tegnekommandoer som rect(), color(), og flytting av origo ved hjelp av translate(). Målet var at elevene skulle kunne eksperimentere på en flate med origo oppe til venstre på et A4-ark, og de skulle kunne tenke i cm. Tilrettelegging av dimensjonene (punkter til cm) ble ferdiglagd i en mal som elevene arbeidet i.
Den første selvstendige oppgaven som ble løst:
Tegn det italienske flagget med en gitt dimensjon (cm) og riktig forhold mellom bredde og høyde (3:2).
Elevene hadde her tilgang til et løsningsforslag som de kunne se på hvis de ville:
void minTegning(){
// sett opp A4-ark med origo oppe til venstre
// og merk siden med et navn du vil bruke
lagA4("jens");
// hoyden
float hoyde=4.0; //cm
// bredde
float bredde=hoyde*1.5;
// litt usikker på om jeg skal la alle kolonnen omgis av en svart strek ?
// jeg skrur den av
noStroke();
// tegner den grønne kolonnen
fill(0,255,0);
rect(0,0,bredde/3,hoyde);
// tegner den midterste hvite kolonnen
fill(255,255,255);
rect(bredde/3,0,bredde/3,hoyde);
// tegner den høyre røde kolonnen
fill(255,0,0);
rect(2*bredde/3,0,bredde/3,hoyde);
// må vel lage en omgivende svart strek
stroke(0,0,0);
noFill();
rect(0,0,bredde,hoyde);
}
Denne introduksjonsdelen gikk relativt problemfritt og den øyeblikkelige visuelle responsen på enkel kode fungerte slik at det var enkelt å eksperimentere. Dette er en av styrkene til Processing, arbeidssyklusen Programmer - Vis er svært kort og enkel.
En typisk oppgave
Oppgaven var formulert slik:
Terninger har lik bredde, lengde og høyde.
Tegn en terning utbrettet slik at når vi klipper og bretter figuren til en 3-dimensjonal figur får vi en terning med sidekanter på 5 cm.
Vi har da lagt opp til følgende arbeidssyklus:
Dette istedet for det som trolig ville være de fleste programmereres først forslag:
Det er noen vurderinger bak problemformuleringen og den løsningsfilosofien det legges opp til.
For det første er det klart at vi kunne ha preparet visningssiden som et ruteark med svake markeringer av cm-ruter. Da ville mer av oppgaven kunne gjøres i den korte løkka Programmer -> Vis. På den annen side kunne vi ha unngått å forberede visningssiden med ferdigsatt pixel-pr-cm. I så fall måtte elevene ha forsøkt seg fram med skalering. Også dette ville øke fokus på løkka Programmer -> Vis. Ulempen er at det ville ta mye fokus vekk fra den pensumbegrunnede problemstillingen. Den løsningen som er valgt er ment på å holde fokus på den matematiske problemløsningen og forståelsen av flate og rom. Hvis noen elever kommer opp med forslag av den typen som er nevnt over er det jo bare å applaudere.
For det andre kan en spørre seg hvorfor i det hele tatt printe, klippe og brette ? Det ville være mulig å diskutere løsningen ut fra å inspisere visningen på skjerm. Det er to momenter her. Det ene er at det å fysisk handtere den utklipte figuren vil, forhåpentlig, bidra til at elever som har problemer med romforståelse kan lære noe av det. En kan også trekke inn et "Doing with Images makes symbols"- resonnement basert på Piagets ideer slik de er beskrevet i et annet innlegg på denne bloggen Piaget og programmering. Det andre momentet er at denne klipp-brett aktiviteten kopler programmeringen til noe utenfor datamaskinen og har både et sosialet og et pedagogisk aspekt. Når elevene er på vei til printeren og når de skal finne seg en saks så er det naturlig å vise fram både gode og "rare" løsninger, og diskutere alternativer. (Det er jo dessuten slik at vi har satt opp en veldig generell arbeidsrutine for å produsere mye annet rart, som f.eks. julepynt, dukketeaterkulisser, visittkort, plakater og jeg vet ikke hva.)
En slags fasitløsning kan se slik ut:
void minTegning(){
// sett opp A4-ark med origo oppe til venstre
// og merk siden med et navn du vil bruke
lagA4("jens");
// Jeg vil tegne en utbrettet terning der alle sider er 5 cm
// det vil si tilsammen 6 kvadrater
// dette kan gjøres på mange måter
// jeg har gjort det ved å tegne et kors
float side=5; // cm
// tegner 4 kvadrater under hverandre
translate(side,0);
rect(0,0,side,side);
translate(0,side);
rect(0,0,side,side);
translate(0,side);
rect(0,0,side,side);
translate(0,side);
rect(0,0,side,side);
// tegner 2 stk på sidene av den nest øverste
// må flytte origo oppover igjen, og til venstre
translate(-side,-2*side);
rect(0,0,side,side);
translate(2*side,0);
rect(0,0,side,side);
}
Andre oppgaver
Noen andre oppgaver som ble lagt fram i samme settingen:
En lukket sylinder (tettet i begge ender) har et gitt volum på 200 kubikk cm.
Bestem diameter og lengde og tegn sylinderen utbrettet.
En pyramide har en kvadratisk grunnflate på 5x5 cm og høyde 6cm.
Tegn pyramiden utbrettet slik at dersom vi klipper og bretter figuren får vi en pyramide med riktige dimensjoner.
En eske har et gitt volum på 170 kubikk centimeter.
Høyden er 2 cm og lengden er 8 cm. Finn bredden og tegn esken utbrettet
Det er mange muligheter. Av begreper trenger vi å regne ut kvadratrota (sqrt()). Dersom trigonometri er en del av pensum vil dette kun kreve å utvide begrepsapparatet med de trigonometriske funksjonene i Processing(sin(),cos()).
Det ble også laget tilbud på oppgaver av en litt annen karakter. Et eksempel var å tegne en ferdig oppmerket fotballbane,og beregne hvor mange meter med linjer det faktisk finnes på en bane.
Oppsummering
Dette eksperimentet vil bli rapportert mer inngående med tanke på hva vi kan lære av det med tanke på matematikkforståelse, sammen med et paralellt eksperiment i barneskolen (7.trinn) med et annet verktøy, Scratch.
Det ser imidlertid ut til at resonnementene omkring kompleksitet i problemstillinger og verktøy er verdt å forfølge. Elevene behersket tilstrekkelige deler av verktøyet raskt og eksperimentet skapte stor interesse og innstasvilje. (Elevene ville ikke gå ut i friminuttene )
I slike eksperimenter må en selvsagt alltid ta hensyn til "Hawtorne-effekten", der oppmerksomhet og det å være med i et forsøk i seg selv skaper en positiv holdning. Selv om vi tar dette med i beregningen står vi igjen med det faktum at kompleksiteten var håndterbar, og at problemformuleringene gir betydelige muligheter for både å fokusere og generalisere.
Linker
Processing
ProgPed
Piaget og programmering
Børres Processing
