Projektarbejde og anvendelsesorienteret undervisning i teknologiforståelse

Almindeligvis består curriculum af en stor mængde struktureret viden, skrev den danske datalogiprofessor Peter Naur (1970) i en artikel, hvor han påpegede vigtigheden af projektaktivitet og orientering mod anvendelse i datalogiuddannelsen. Vellykket projektarbejde afhænger af kompetent anvendelse af visse teknikker, skrev han videre, og det virkeligt svære er ikke at mestre hver af disse teknikker isoleret. I stedet advokerede han for, at teknikker læres i den kontekst, de skal anvendes i.

I den omtalte artikel talte Peter Naur ganske vist om videregående uddannelse, men i en nutid, hvor datalogi er på vej ind i folkeskolen som del af forsøgsfaget teknologiforståelse, står det mig klart, at hans teorier gælder i også denne kontekst. Projektarbejde kræver øvelse og erfaring, og det er uhensigtsmæssigt først at lære denne måde at arbejde på, når vi senere står i et job – der er behov for at udvikle sådanne kompetencer i vores uddannelse, påpegede Naur. På det grundlag diskuterede han, hvorvidt projektaktivitet kan indgå som arbejdsform i datalogiuddannelsen. I det følgende skitserer jeg hans tanker herom, oversat til dansk og til egne tanker om en folkeskolekontekst som et fagdidaktisk bidrag til det fag, vi i dag kalder teknologiforståelse.

Projektaktivitet og datalogi

Projektaktivitet defineres af Peter Naur ret simpelt som de aktiviteter, der foregår som en del af et projekt – mere præcist ”arbejdet med at løse et delvist defineret, ikke for lille, men specifikt problem, der involverer design og planlægning af nye konstruktioner som væsentlige dele”. I arbejdet med computere kunne det være udviklingen af et program – et stykke software.

Naur karakteriserer projektaktivitet med flere indbyrdes forbundne aspekter. For det første involverer det problemløsning, og for det andet problemdefinition. I forhold til sidstnævnte påpeger han, at definitionen af et problem ofte er ret ufærdig og måske logisk inkonsistent, og det er derfor ”en vigtig del af projektaktivitet at diskutere definitionen af problemet, afklare det, gøre det mere konkret, ændre det, opdage modsætninger i det samt diskutere og opløse modsætninger”. Derudover involverer projektaktivitet typisk, at en gruppe af mennesker er engagerede og arbejder parallelt på projektet. I folkeskolekontekst kan vi som datalogiske projekter forestille os udvikling af små programmer. For eksempel har jeg i samarbejde med ph.d. i datalogi, Martin Dybdal, tidligere i år afprøvet et projektarbejde, hvor eleverne i grupper arbejdede med at udvikle et datalogisk design, der kunne hjælpe mennesker med at udlede mindre CO2 gennem deres elektricitetsforbrug (Caeli & Dybdal, forthcoming).

På mange akademiske områder (dog ikke for eksempel engineering) har der primært været en interesse i viden og sandhed frem for design og konstruktion, skriver Naur. Han citerer i sin artikel George Forsythe, grundlægger af Stanford University's Computer Science department (i 1965) og af selve begrebet computer science (i 1961), for i 1964 at have udtalt, at design lod til at være en andenrangs intellektuel aktivitet for en datidig matematiker. I den henseende påpeger Naur, at der er et stærkt behov for orientering mod projektarbejde, når dataloger for eksempel arbejder med udvikling af basal software i samarbejde med matematikere. Samarbejde anser han for at være et andet nøgleord og påpeger, at der inden for mange fagområder er en tradition for at arbejde på meget individualistiske måder, hvilket står i stærk kontrast til den form for projektarbejde, han taler for. Desuden understreger han, at man bør arbejde tæt sammen med praktikere og fagpersoner fra andre områder i udviklingen af applikationsprogrammer, dvs. almene programmer til brugere, som sigter mod løsning af en opgave eller tjener et vist formål – for eksempel et tekstbehandlingsprogram eller et computerspil.

Problemløsning og designteknikker

At løse problemer er en stor del af projektaktivitet. Det indebærer både at designe en overordnet plan for projektet samt selve arbejdet med mindre dele. Selv de mindste detaljer kan ses som problemer, der skal løses. Da Naur skrev sin tekst i 1970, eksisterede der ikke så meget litteratur om problemløsning som i dag, men han refererer til Hyman og Anderson, der oplister otte principper for problemløsning:

1. Gennemgå elementerne i problemet i hurtig rækkefølge flere gange, indtil der opstår et mønster, der omfatter alle disse elementer samtidig.
2. Udsæt vurderinger. Spring ikke til konklusioner.
3. Undersøg miljøet. Varier den tidsmæssige og rumlige organisering af materialerne.
4. Udarbejd en ny løsning efter den første.
5. Evaluer dine egne ideer kritisk. Evaluer andres konstruktivt.
6. Når du sidder fast, skal du ændre dit repræsentationssystem. Hvis en konkret repræsentation ikke fungerer, prøv da en abstrakt en og omvendt.
7. Tag en pause, når du sidder fast.
8. Tal om dit problem med nogen.

En sådan liste, skriver Naur, kan i øvrigt minde os om, at vanskeligheden ved projektarbejde ikke ligger i at forstå løsrevne elementer, men i kompetent at kunne kombinere dem.

Desuden er designteknikker påkrævet i projektarbejde, fremhæver han, herunder at foretage rimelige kompromisser omkring modstridende specifikationskrav. I det føromtalte designeksperiment skulle eleverne for eksempel designe et fysisk objekt, der blandt andet integrerede en LED-strip, de skulle programmere til at indhente realtidsdata om CO2-udledningen i Danmark. Ved hjælp af blandt andet farver og antal tændte LED’er skulle deres design kunne vise brugeren, hvornår det var mest hensigtsmæssigt at anvende elektricitet med det mål at udlede mindre CO2. Modstridende specifikationskrav kunne i den forbindelse vedrøre programmeringen: Var det for eksempel mest vigtigt, at objektet var tændt hele tiden, eller skulle der indgå en form for dvalefunktion? Eller vedrøre det fysiske design: Var det bedst, at det var synligt i eksempelvis stuen, så brugeren hele tiden lagde mærke til det, eller skulle det indgå som en skjult del af interiøret?

Designteknikker er ifølge Naur det område, hvor problemløsningsprincipper er til mindst hjælp, og hvor meget er overladt til erfaring og talent. Han refererer til en designtilgang af Christopher Alexander:

• Først oplistes alle designkrav.
• Dernæst gennemgås alle kravene, og det besluttes, om de er relaterede eller ikke, hvorefter de interne relationer anvendes til at gruppere kravene, så de stærkt relaterede krav er i samme gruppe.
• Til sidst udvikles designet ved at starte med de stærkest relaterede krav, og først senere kobles de mere løst relaterede krav på.

I forhold til design af software refererer Naur desuden til Randell, der skelner mellem en bottom-up-tilgang til design, hvor designeren starter med de mest enkle funktioner og lidt efter lidt bygger mere komplicerede på for til sidst at ende med det færdige produkt, der imødekommer alle krav, og en top-down-tilgang, hvor designeren tager udgangspunkt i det færdige systems egenskaber og lidt efter lidt opdeler det i mindre enheder, indtil det er udtrykt i form af systemets mest enkle funktioner. En bemærkning hertil, som både Naur og Randell selv fremførte, er, at en designproces ikke kan følge en ren bottom-up- eller top-down-tilgang, men må følge et meget mere kompliceret ræsonnementsmønster. Den mentale sti, man følger i et kompliceret design, vil afhænge af ens tidligere erfaringer som designer.

Projektdokumentation og designprocessen

Udover selve programmet bør projektet også omfatte dokumentation. Som minimum en beskrivelse af programmets funktioner med almindelige betegnelser samt forklaringer omkring input og output. Dokumentation bør ifølge Naur være en integreret del af designprocessen og ikke noget, man først laver bagefter. Dette pointerer han som vigtigt – eksempelvis for at de forskellige mennesker, der samarbejder om et projekt, kan referere til hinandens arbejde, men også fordi nedskrevne formuleringer er påkrævede i systematisk og bevidst arbejde. ”Der er stor forskel på at gennemgå et argument mentalt og at berette det skriftligt”, skriver han. ”At skrive ordene ned på papir tvinger dig til at overveje hvert trin mere omhyggeligt og vil ofte give anledning til revidering og forbedring af løsningen.” Her refererer han til det af Hyman og Andersons principper, der lyder: Tal om dit problem med nogen.

For brugeren er en dokumentation værdifuld, da brugeren dermed bliver i stand til at følge samme mentale sti som designeren og opnå større forståelse for den valgte løsning. Derudover er den også vigtig med henblik på at kunne ændre noget i løsningen senere, da man på den måde har mulighed for at gennemskue, hvor væsentlig en given ændring er i det samlede billede – for således at minimere risikoen for at forværre løsningen.

I dag, hvor der i samfundet i høj grad ’eksperimenteres’ med dataovervågning og handles med vores alles data, vil jeg fremhæve transparens over for brugeren som en tredje væsentlig grund. Hvis vi som brugere af et produkt kan læse en beskrivelse af designet, skrevet med almindelige ord, og hvor henholdsvis input og output er tydeligt, får vi mulighed for at opnå forståelse for systemets argumentation og formål samt tage stilling til, om vi ønsker at bruge systemet på de præmisser. Dette kan – og efter min mening bør – der også arbejdes med i folkeskoleregi. Både når eleverne designer deres egne små digitale systemer, samt når de forsøger at gennemskue andres (eksempelvis applikationer på deres smartphone).

Brug af tjeklister

Tjeklister beskriver Naur som et simpelt, men vigtigt, redskab til at holde styr på punkter, man skal huske eller tjekke op på på bestemte tidspunkter i projektarbejdet. Han refererer til, at læreren med sin viden kan formidle passende procedurer til eleverne, men inddrager i sin tekst eksempler i form af de følgende to tjeklister:

Store beslutninger i design af datasystemer

• Hvad skal gøres af mennesker, og hvad skal gøres af maskinen i den samlede databehandling?
• Hvilke enheder og datarepræsentationer skal anvendes på brugerfladen mellem menneske og maskine?
• Hvordan er det samlede systems behandlingscyklus?
• Hvilke programmer kræver systemet, og hvilken funktion har hvert enkelt?
• Hvordan gemmes og repræsenteres de større samlinger af data?
• Behandling af mennesker: Hvem skal gøre hvad, hvor, og hvornår, og hvor ofte?
• Hvilke designmål kan ikke indfries, og hvorfor?

Tjekpunkter i et foreslået design

• Hvor godt er målene indfriet?
• Designets enkelhed: Tjek, at designet ikke har nogle unødvendige dele eller funktioner.
• Performance: Estimer systemets anslåede performance.
• Stabilitet: Er systemet fortsat under kontrol, hvis det udsættes for isolerede tilfælde af funktionsdefekter eller andre fejl?
• Grad af synlighed: Har de ansvarlige mulighed for at holde styr på behandlingen hele tiden?
• Omskiftelighed: Er designet udført med tanke på mulige senere ændringer?

Behovet for gruppearbejde

Projektarbejde indebærer meget arbejde, og det er nødvendigt, at det udføres af mennesker, der arbejder sammen i grupper, pointerer Naur. Dette er tilstrækkelig grund til at insistere på, at projektarbejde i undervisningen bør indebære, at elever arbejder i grupper. En mere specifik grund, siger han, er, at visse faser i arbejdet med et projekt i dybere forstand involverer et samspil mellem flere mennesker med forskellige interesser. For eksempel bør beslutninger i den indledende fase omkring projektets specifikke mål tages i en diskussion mellem mennesker, der repræsenterer de forskellige grupper af mennesker, som vil blive berørt af det system, der skal konstrueres.

En egen note hertil er det nutidige fokus på, at langt flere mænd end kvinder vælger at uddanne sig som dataloger. Det er uhensigtsmæssigt, hvis det udelukkende er mænd, der udarbejder systemer, som også kvinder skal anvende. Diversitet handler i den forbindelse dog ikke kun om køn, men overordnet om, at forskellige mennesker, der repræsenterer forskellige brugere med forskellige interesser og værdier, involveres i projektet. For at give et komplet billede af virkelighedens arbejde med projekter, må projektarbejde altså også foregå som gruppearbejde i skolen. Naur påpeger den vanskelighed herved, at eleverne muligvis ikke naturligt repræsenterer forskellige interesser – men at denne udfordring kan imødekommes ved, at eleverne i en gruppe indtager forskellige roller i diskussionerne, hvor de foregiver at have forskellige interesser. Altså som en del af deres læringsproces.

Implementering af projektarbejde

Naur argumenterer for, at der ikke er nogen (gyldig) grund til, at eleverne først skal have erhvervet sig passende viden at bygge på, før de introduceres til projektarbejde i deres uddannelse. Han taler om videregående uddannelse, men jeg overfører det her til også at gælde i folkeskolen, eftersom han påpeger, at der faktisk omvendt er stærke grunde til, at projektarbejde bør forekomme tidligt i uddannelse. Projektarbejde kan nemlig tage udgangspunkt i den viden, man har – uanset om den er ’komplet’ – med udgangspunkt i simple systematiske principper. Desuden tager det tid og erfaring virkelig at få fat i principperne. Med andre ord kræver det også, at eleverne har oplevet forgæves forsøg på at løse problemer. Derudover nævner Naur også, at de forsøg på at løse problemer, som er opstået i projekter tidligt i uddannelsen – uanset om de lykkedes eller mislykkedes – muligvis kan motivere eleverne i senere projektarbejde.

Dog bør projekter i den tidlige del af uddannelsen være af begrænset størrelse – hvilket skaber det problem, at eleverne måske ikke erfarer alle dele af en problemløsningsproces. ”Dette problem er kun et af mange problemer med uddannelse, der stammer fra det faktum, at et uddannelsesmiljø ikke kan være som den virkelige verden i enhver henseende. Den eneste rimelige måde at overvinde denne vanskelighed er at insistere på anvendelse af de rette teknikker, selv i mindre projekter”, pointerer Naur.

Evaluering af projektarbejde

Introduktion af projektarbejde i formel uddannelse skaber nogle udfordringer i forhold til evaluering og karaktergivning, forklarer Naur. ”På grund af de frie valg, eleverne har i arbejdet, kan acceptable løsninger afvige meget på mange forskellige måder, og en pålidelig sammenligning mellem dem kan blive vanskelig og tidskrævende.” For at imødekomme dette problem skelner Naur mellem forskellige formål med evaluering og karaktergivning og italesætter, at evaluering – i stedet for at blive en periodisk tilføjelse til undervisningen – kan anvendes til at vejlede elevernes opmærksomhed derhen, hvor den er mest hensigtsmæssig. Her nævner han væsentligheden af omhyggeligt udvalgte evalueringskriterier, der svarer til de kompetencer, eleverne skal udvikle i hensigtsmæssig problemløsning. I den forbindelse understreger han, at ”disse kriterier skal formidles til eleverne, når de får problemet, så de kan vejlede dem i deres arbejde”.

Derudover italesætter han, at det som supplement til lærerens normale karaktergivning kan være givende med interne evalueringer eleverne imellem, hvor de altså evaluerer og diskuterer hinandens projekter – men han påpeger, at en sådan form for evaluering ikke bør fungere som karaktergivning. Så mister den sin værdi.

Afrunding

Dette indlæg er tænkt som et fagdidaktisk bidrag til arbejdet med datalogi- og teknologiprojekter i folkeskolen med sigte på, at datalogiske kompetencer udvikles i anvendelsesorienterede kontekster og ikke som enkeltelementer eller isoleret viden, løsrevet fra brug.

Peter Naur har gjort sig mange og grundige overvejelser herom siden 1960’erne, som også kan inspirere vor nutidige kontekst, hvor en af de sager, han brændte stærkt for og gentagne gange pegede på vigtigheden af, endelig er ved at blive realiseret – nemlig at datalogi kommer ind i folkeskolen, så alle lærer at forstå, hvordan computere fungerer i det stærkt digitaliserede samfund, vi alle lever i.

Referencer

Caeli, E. N. & Dybdal, M. (forthcoming). Teknologiforståelse i skolens praksis: datalogisk design til autentisk problemløsning. Manuskript indsendt mhp. publicering.

Naur, P. (1970). Project activity in computer science education. Calcolo, 7(1). https://doi.org/10.1007/BF02575555