Onderrig van probleemoplossing en algoritme-ontwerp

Verskeie kodes wat met die onderrig van probleemoplossing en algoritme-ontwerp verband hou, het tydens die data-insameling na vore gekom – naamlik die tyd wat aan algoritme-ontwerp bestee moet word, beplanning, en waar algoritme-ontwerp by die onderrig van programmering in Scratch moet inpas. Dit was duidelik dat onderwysers die bevordering van logiese denke en die aanleer van probleemoplossing as die belangrikste aspekte van Scratch-onderrig beskou. Die

meerderheid onderwysers was eenstemmig dat algoritme-ontwerp en probleemoplossing belangrike vaardighede was om te onderrig en daarom het meeste onderwysers daarop aangedring dat ʼn algoritme of vloeidiagram ontwerp moes word voordat die oplossings in Scratch geprogrammeer kan word.

Ek dink dit gaan alles oor logiese denke, probleemoplossing. Eerstens moet hulle enige probleem kan oplos deur middel van logiese denke. Dit is, dink ek, die belangrikste. Ek het báie tyd spandeer aan vloeidiagramme en algoritmes (P1). Ek dink ek het baie tyd spandeer aan logika en dalk te laat met Scratch begin (P1).

Probleemoplossing is die belangrikste (P5).

Met elke program wat my kinders skryf as hulle ’n opdrag kry, moet hulle eers ’n algoritme of ʼn vloeidiagram ontwerp (P3).

Dit is ʼn proses van analiseer die vraag, ontwerp ʼn toevoer–verwerking–afvoer- diagram en skryf dan die pseudokode. Daarna programmeer hulle. Dit moet laaste gebeur (P5).

In die begin doen ons ongeveer ’n week lank algoritmes, daarna bly ek daarop fokus (P3).

Die begin van die jaar, ja die begin van die jaar, begin ek met algoritmes (P4). Die eerste ding is maar om heeltemal die rekenaars af te sit. Daardie eerste hoofstuk is goed ontwerp in Scratch handboeke om net vloeidiagramme en die vloei van instruksies te doen (P6).

Deelnemer P2 het aangevoer dat leerders nie daarvan hou om algoritmes te ontwerp nie, maar het aanbeveel dat leerders dit wel moet doen, aangesien dit hulle help om programme te beplan.

Hulle is nie gelukkig oor die papierwerk nie, maar hulle leer baie. Hulle leer dat hulle meer moet beplan (P2).

Behalwe beplanning, help die ontwerp van algoritmes, volgens deelnemer P6, ook om deursettingsvermoë by leerders te kweek.

Hulle het daardie gevoel gekry van, komaan, ek moet nou dit doen (P6).

Die eerste hoofstuk in die handboek handel oor algoritme-ontwerp en gevolglik het die deelnemende onderwysers gerapporteer dat hulle eers ʼn tyd lank algoritmes behandel het. Die KABV (DBE, 2011:21) stel ook hierdie werkswyse voor. Volgens deelnemer P6 is ʼn verdere voordeel van hierdie werkswyse dat dit klasdissipline bevorder en leerders op programmering laat fokus.

Die kinders het baie vloeidiagramme uitgewerk en dit het baie gehelp met klasdissipline, want mens sukkel verskriklik in programmering as jy agterkom almal sukkel met een probleem, om almal se aandag weer op die bord te kry. My onderrigstrategie is om aan die begin van die jaar regtig vir die kinders te laat fokus waarheen ons op pad is (P6).

Daar was egter onderwysers wat meen dat algoritmes nie so belangrik is nie. Twee onderwysers was van die opinie dat algoritmes nie met die skryf van elke program afgedwing moet word nie, maar dat leerders dit tog gereeld moet doen. Daar is ook gemeld dat algoritmes vir toetsing gebruik kan word.

Hulle moet die algoritme toets met die toetsdata. As ek nou klaar verduidelik het, dan vra ek hulle om vinnig ʼn plan neer te skryf hoe hulle dit gaan doen. Daar is nie altyd tyd om ’n algoritme te doen nie, maar mens kan dit so twee keer ’n week inpas (P4).

Deelnemer P1 het nie in 2012 vereis dat ʼn algoritme voor elke Scratch-program ontwerp moet word nie, maar was van voorneme om dit in die toekoms so te doen.

Ek het nie verlede jaar nie maar ek dink ek gaan dit hierdie jaar so doen. Dat hulle eers hulle denke oopkry en dink (P1).

Deelnemer P7 was die enigste onderwyser wat nie algoritme-ontwerp in 2012 toegepas het nie en steeds nie dink dis belangrik vir Scratch-onderrig nie. Deelnemer P8 het ook nie algoritme-ontwerp in 2012 toegepas nie, maar erken dat dit problematies was en sal dit nie weer in die toekoms so doen nie.

Ek het hierdie jaar [2013, Scratch] met algoritmes begin, waar ek laasjaar [2012, Scratch] eers net begin programmeer het en dit was ’n fout, want as mens met algoritmes begin, is dit vir hulle baie vervelig en hulle weet nie hoekom nie en hulle weet nie waarom dit gedoen word nie. Die graad 10-handboeke begin met algoritmes en dit werk glad nie so nie. Ek sal persoonlik eers programmering vir hulle probeer leer, ek dink die speel-deel is vir hulle lekker (P7).

Ek het die vorige jaar [2012] nie algoritmes gedoen nie, net weggeval met Scratch. Eers algoritmes en dan Scratch. Ek gaan nou so werk (P8).

Een of ander vorm van beplanning tydens probleemoplossing was egter vir die meeste onderwysers belangrik aangesien leerders nie ʼn probeer-en-tref-manier van probleemoplossing in Scratch moet toepas nie. Die aard van Scratch kan maklik tot gevolg hê dat probeer-en-tref-maniere aangeleer word (sien 2.3.1.2).

Want anders trek hulle alles [in met blokke kode] en sien dit werk nie en haal weer uit en sit weer in en dan is daar geen beplanning nie (P1).

Onderwysers was egter onseker oor hoe om probleemoplossing en algoritme- ontwerp by Scratch-onderrig te integreer. Scratch is op die oog af ʼn eenvoudige programmeertaal en dit is teoreties moontlik om oplossings te ontwikkel sonder om algoritme-ontwerp aanvanklik toe te pas. Dit is duidelik dat onderwysers nie die omvang en waarde van Scratch aanvanklik besef het nie.

Aanvanklik toe ek Scratch gesien het, het ek gedink dis ’n groot speletjie en eintlik ’n grap, want dis net insleep-programmering, maar toe ons nou ’n bietjie meer in die program ingaan, toe ek ook probeer het om ʼn program te skryf, toe sien ek daar is darem lyf daaraan, dat hulle basiese konsepte gaan leer (P3).

Uit bostaande kan die afleiding gemaak word dat onderwysers oor die algemeen glo dat algoritme-ontwerp noodsaaklik is. Sommige onderwysers het wel algoritme- ontwerp as ʼn aparte tema hanteer en dit nie met die onderrig van Scratch- programmering geïntegreer nie. Dit is omdat die handboek dit net in een hoofstuk hanteer het en verskillende opinies bestaan het oor die plek van algoritme-ontwerp tydens die onderrig van programmering.

Toe ons handboeke gekry het, toe probeer ons weer teruggaan [na algoritmes]. Die kinders was toe al vir twee weke gewoond om in Scratch te werk en jy kan nie dit in daardie volgorde doen nie, glad nie (P6).

Met al die bostaande in ag geneem, kan samevattend gesê word dat onderwysers algoritme-ontwerp en probleemoplossing as ʼn integrale deel van die proses van programmering sien. Baie tyd word aan die onderrig van algoritmes en probleemoplossing afgestaan alhoewel almal dit nie geïntegreerd met Scratch- programmering onderrig nie. Sommige deelnemers het gevoel dat Scratch ʼn maklike programmeertaal is en dat dit onnodig is om met algoritme-ontwerp te begin. Ander deelnemers het egter, ongeag die feit dat dit vir leerders moeilik en vervelig was, met algoritme-ontwerp begin en so gepoog om deursettingsvermoë en beplanning by leerders te kweek. Die feit dat onderwysers soveel verskillende strategieë probeer het, en van strategieë verwissel het, dui op die komplekse aard van die saak en bevestig die opvatting dat algoritme-ontwerp as die moeilikste fase van die programmeringsproses beskou kan word (sien 2.3). Uiteindelik het almal, met die uitsondering van deelnemer P7, tot die gevolgtrekking gekom dat algoritme-ontwerp, ook tydens die onderrig van Scratch, deurlopend toegepas moet word.

Die onderrig van probleemoplossing en algoritme-ontwerp is egter slegs een afdeling van die onderrig van programmering. Daar is verskeie ander programmerings-

beginsels en -begrippe wat onderrig moet word (sien figuur 2.9), soos wat ook uit die data-analise oor die onderrig van Scratch-programmering na vore gekom het.