Project:Physical Computing: verschil tussen versies
(28 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
Regel 1: | Regel 1: | ||
{{Zijbalk Physical Computing}} | {{Zijbalk Physical Computing}} | ||
== Opzet en resultaten == | == Opzet en resultaten == | ||
[[Physical Computing-thema | Physical Computing]] is een rijk onderwerp. De mogelijke toepassingen zijn enorm. In de krant is regelmatig iets te lezen over robotica, zelfrijdende auto's, zorgrobots, smart cities, etc). En de beschikbaarheid van goedkope hardware maakt het mogelijk om de leerlingen zelf systemen te laten bouwen. | |||
Het doel van de module is docenten en leerlingen kaders en ondersteuning bieden. Dat betekent dat de module het volgende gaat bieden. | Enkele uitgangspunten: | ||
* We willen laten zien wat toepassingen zijn van physical computing in de wereld om ons heen. Denk aan toepassingen in de zorg, transport, medische wereld, veiligheid, etc. Daarmee willen we een brede groep leerlingen aanspreken. | |||
* We laten zien dat het voor de leerlingen heel goed haalbaar is om zelf zo'n systeem te ontwikkelen aan de hand van diverse voorbeelden (waaronder ook kunstzinnige/creatieve systemen). | |||
* We willen dat de leerlingen zelf een systeem of prototype ontwerpen en ontwikkelen. Daarbij zijn werkwijzen als iteratief werken, samenwerken en evalueren van belang. Het is daarbij ook mogelijk dat de klas een samenhangend prototype ontwerpt en ontwikkelt, bijvoorbeeld rondom het thema smart-city. | |||
* We willen dat de leerling in staat is om keuzes bij de ontwikkeling te onderbouwen, specifiek de keuzes voor de sensoren en actuatoren. | |||
* We willen dat de leerling in staat is om een systeem te evalueren op aspecten als tijdigheid, betrouwbaarheid en functionaliteit. | |||
* De module bestaat uit drie delen: toepassingen in de maatschappij, bouwstenen voor physical computing en zelf ontwikkelen. | |||
* Het eerste deel van module is platform-onafhankelijk. Het platform-afhankelijke deel wordt voor drie platforms uitgewerkt: Arduino (hogere moeilijkheidsgraad, Lego-mindstorms en Micro:Bit/Blockly (lagere moeilijkheidsgraad). | |||
* We bieden de bouwstenen aan op basis waarvan de leerling een systeem of prototype kan bouwen. | |||
* We willen dat de leerling is staat is om een systeem te modelleren/beschrijven met behulp van toestandsdiagrammen (eindige automaten). | |||
* Centrale begrippen zijn: physical computing, sensoren, actuatoren, betrouwbaarheid, tijdigheid, functionaliteit, automaten/toestandsdiagrammen. | |||
De module is geen 'boek' dat van begin tot eind moet worden doorlopen. Het doel van de module is docenten en leerlingen kaders en ondersteuning bieden. We verwijzen deels naar externe bronnen. Dat betekent dat de module het volgende gaat bieden. | |||
=== Leerdoelen en concepten === | === Leerdoelen en concepten === | ||
Regel 20: | Regel 33: | ||
In deze module legt de leerling een verbinding tussen theorie en praktijk. De leerling leert op basis van de theorie zelf een fysiek digitaal artefact te ontwerpen en ontwikkelen en daarmee te experimenteren. Anderzijds zou het mooi zijn als de leerling ook begrip ontwikkelt door het experimenten, ontwerpen en ontwikkelen (of dat kan is echter nog weinig bewijs voor). | In deze module legt de leerling een verbinding tussen theorie en praktijk. De leerling leert op basis van de theorie zelf een fysiek digitaal artefact te ontwerpen en ontwikkelen en daarmee te experimenteren. Anderzijds zou het mooi zijn als de leerling ook begrip ontwikkelt door het experimenten, ontwerpen en ontwikkelen (of dat kan is echter nog weinig bewijs voor). | ||
De grote beschikbaarheid van goedkope bordjes, sensoren, actuatoren maakt het mogelijk om de leerlingen veel zelf te laten experimenteren en | De grote beschikbaarheid van goedkope bordjes, sensoren, actuatoren maakt het mogelijk om de leerlingen veel zelf te laten experimenteren en ontwikkelen. De module biedt de mogelijkheid tot tinkering. Steeds in kleine stapjes iets uitproberen en ervaring opdoen en op die manier tot oplossingen komen. | ||
Een | De leerlingen zullen uiteindelijk op basis van een redelijk open probleem een fysiek digitaal artefact gaan ontwerpen en ontwikkelen. Slechts ter illustratie: bedenk, ontwerp en ontwikkel een systeem dat een probleem in je eigen omgeving oplost. Een automatische stofopveger, een plant-watergeef-systeem, een oefen-eend, etc. Het kan ook een prototype zijn. | ||
=== Contexten === | === Contexten === | ||
Regel 72: | Regel 83: | ||
1. Een reeks cases. Daarin worden binnen een context de toepassingen van physical computing getoond en behandeld. Deze toepassingen worden vanuit meerdere kanten geanalyseerd door de leerlingen, aan de hand van onder meer de volgende vragen: | 1. Een reeks cases. Daarin worden binnen een context de toepassingen van physical computing getoond en behandeld. Deze toepassingen worden vanuit meerdere kanten geanalyseerd door de leerlingen, aan de hand van onder meer de volgende vragen: | ||
* Welke sensoren en actuatoren worden hier gebruikt? | * Welke sensoren en actuatoren worden hier gebruikt? | ||
* Wat is de werking van het systeem, daarbij de sensoren en actuatoren in acht nemend, | * Wat is de werking van het systeem, daarbij de sensoren en actuatoren in acht nemend, en nadruk op tijdigheid, betrouwbaarheid en functionaliteit. | ||
* Wat zijn de beperkingen van het systeem? | * Wat zijn de beperkingen van het systeem? | ||
* Wat zijn de maatschappelijke consequenties? | * Wat zijn de maatschappelijke consequenties? | ||
Deze vragen moeten worden aangevuld en aangescherpt, op basis van de precieze leerdoelen die nog moeten worden geformuleerd. | Deze vragen moeten worden aangevuld en aangescherpt, op basis van de precieze leerdoelen die nog moeten worden geformuleerd. | ||
De reeks cases laten zien wat de state-of-the-art is ten aanzien van physical computing. Wellicht dat de leerlingen hier al kunnen kiezen uit verschillende cases. | De reeks cases laten zien wat de state-of-the-art is ten aanzien van physical computing en waar de huidige uitdagingen liggen. Wellicht dat de leerlingen hier al kunnen kiezen uit verschillende cases. | ||
2. Een reeks gesloten opdrachten waarbij leerlingen een fysiek digitaal artefact moeten nabouwen. Ze leren hierbij welke bouwstenen beschikbaar zijn en hoe je die kunt combineren. Het legt de basis voor het derde hoofdcomponent (zie hieronder). De leerlingen kunnen kiezen uit verschillende opdrachten. | 2. Een reeks gesloten opdrachten waarbij leerlingen een fysiek digitaal artefact moeten nabouwen. Ze leren hierbij welke bouwstenen beschikbaar zijn en hoe je die kunt combineren. Het legt de basis voor het derde hoofdcomponent (zie hieronder). De leerlingen kunnen kiezen uit verschillende opdrachten. | ||
Regel 96: | Regel 107: | ||
=== Gebruik van hardware === | === Gebruik van hardware === | ||
Arduino’s | Arduino’s, MicroBit, Lego Mindstorms, etc, er is veel hardware verkrijgbaar. Het zou mooi zijn als de module de kaders kan bieden voor hoofdcomponent 2 zoals hierboven beschreven, zonder dat de docent verplicht wordt te kiezen voor één specifiek platform. Binnen de module werken we deze kaders op basis van drie platforms meer in detail uit voor hoofdcomponent 2 hierboven. Docenten die kiezen voor een ander platform krijgen daarmee die ruimte. Docenten die meer houvast willen vinden die in de specifiek uitwerking. | ||
<div style="background-color:lightblue;"> | <div style="background-color:lightblue;"> | ||
Concreet resultaat module | Concreet resultaat module | ||
Regel 115: | Regel 126: | ||
Aandachtspunten voor docenten en docentenhandleiding | === Aandachtspunten voor docenten en docentenhandleiding === | ||
Wat is belangrijk om leerling op te coachen bij het experimenteren, ontwerpen en ontwikkelen? Denk bijvoorbeeld aan het belang van werken in kleine stapjes en het testen van tussenoplossingen. Waar liggen misconcepten op de loer? Waar hebben leerlingen moeite mee? Wat zijn handige trucjes om effectief te kunnen werken? De module geeft allerlei aanwijzingen ter ondersteuning van de docent, op basis van eerdere ervaringen en op basis van testresultaten. | Wat is belangrijk om leerling op te coachen bij het experimenteren, ontwerpen en ontwikkelen? Denk bijvoorbeeld aan het belang van werken in kleine stapjes en het testen van tussenoplossingen. Waar liggen misconcepten op de loer? Waar hebben leerlingen moeite mee? Wat zijn handige trucjes om effectief te kunnen werken? De module geeft allerlei aanwijzingen ter ondersteuning van de docent, op basis van eerdere ervaringen en op basis van testresultaten. | ||
<div style="background-color:lightblue;"> | <div style="background-color:lightblue;"> | ||
Regel 156: | Regel 167: | ||
! Naam | ! Naam | ||
! Rol en expertise | ! Rol en expertise | ||
|- | |- | ||
Regel 164: | Regel 174: | ||
Coördinator Bètasteunpunt Zuid-Holland | Coördinator Bètasteunpunt Zuid-Holland | ||
Enkele lesmodules ontwikkeld zoals de NLT-module Spelen met Digitale Techniek. | Enkele lesmodules ontwikkeld zoals de NLT-module Spelen met Digitale Techniek. | ||
|- | |- | ||
Regel 172: | Regel 182: | ||
Veel ervaring met de inzet van hardware zoals Arduino, MicroBit, etc. | Veel ervaring met de inzet van hardware zoals Arduino, MicroBit, etc. | ||
Initiatiefnemer van ICT in de wolken. | Initiatiefnemer van ICT in de wolken. | ||
|- | |- | ||
| | | Hans Konings | ||
| | | Docent informatica Joke Smit College | ||
Docent | |||
|- | |- | ||
Regel 188: | Regel 194: | ||
Veel ervaring met de inzet van Arduino en dergelijke in de klas. | Veel ervaring met de inzet van Arduino en dergelijke in de klas. | ||
Heeft veel materiaal ontwikkelt en gepubliceerd op http://doc-type.nl/ | Heeft veel materiaal ontwikkelt en gepubliceerd op http://doc-type.nl/ | ||
|- | |- | ||
Regel 194: | Regel 199: | ||
| Docent informatica GSR Rotterdam & Beleidsmedewerker ICT. | | Docent informatica GSR Rotterdam & Beleidsmedewerker ICT. | ||
Veel ervaring met onder meer de inzet van Lego Mindstorms in de klas. | Veel ervaring met onder meer de inzet van Lego Mindstorms in de klas. | ||
|} | |} | ||
Regel 208: | Regel 212: | ||
=== Planning === | === Planning === | ||
[https://docs.google.com/spreadsheets/d/1FAD2Bse93Unf-Q8VXF45J2BeNeUPbeT6CfyjsoGc_0A/edit?usp=sharing Planning eerste versie] | |||
Hieronder staat een globale planning. De eerste versie die in december moet worden opgeleverd kan bijvoorbeeld bestaat uit een minimale variant, waarin minstens één uitwerking (maak kan ook meer) van elk van de drie hoofdcomponenten is opgenomen, inclusief docentenhandleiding, etc. Vervolgens breiden we de module uit door uitwerkingen in elk van de drie hoofdcomponenten toe te voegen. | Hieronder staat een globale planning. De eerste versie die in december moet worden opgeleverd kan bijvoorbeeld bestaat uit een minimale variant, waarin minstens één uitwerking (maak kan ook meer) van elk van de drie hoofdcomponenten is opgenomen, inclusief docentenhandleiding, etc. Vervolgens breiden we de module uit door uitwerkingen in elk van de drie hoofdcomponenten toe te voegen. | ||
Regel 279: | Regel 285: | ||
|- | |- | ||
| [[/Dinsdag 19 sep]] van | | [[/Dinsdag 19 sep]] van 20.00 – 21.00 | ||
| Via Skype | | Via Skype | ||
Regel 287: | Regel 293: | ||
|- | |- | ||
| [[/Maandag 25 sep]] van | | [[/Maandag 25 sep]] van 20.00 – 21.00 | ||
| Via Skype | | Via Skype | ||
|- | |- | ||
| [[/Donderdag 5 okt]] van 16.00 – 18.30 | | [[/Donderdag 5 okt]] van 16.00 – 18.30 | ||
| in de buurt van | | in de buurt van station Breukel | ||
|- | |- | ||
| [[/Woensdag 11 okt]] van 17.00 – 18.00 | | [[/Woensdag 11 okt]] van 17.00 – 18.00 | ||
| | | Geannuleerd | ||
|- | |- | ||
| [[/ | | [[/Donderdag 26 okt]] van 16.00 – 18.30 | ||
| in de buurt van Utrecht CS | | in de buurt van Utrecht CS | ||
Regel 335: | Regel 341: | ||
|- | |- | ||
| [[/ | | [[/Donderdag 11 jan]] van 16.00 – 18.30 | ||
| in de buurt van Utrecht CS | | in de buurt van Utrecht CS | ||
|} | |} | ||
== | == Concepten, leerdoelen en vaardigheden == | ||
=== | |||
=== Eindexamenprogramma === | |||
De basis is het nieuwe eindexamenprogramma: | De basis is het nieuwe eindexamenprogramma: | ||
[[Bestand:Examenprogramma1.png|400px]] | [[Bestand:Examenprogramma1.png|400px]] | ||
In het nieuwe examenprogramma worden drie vaardigheden uitgelicht, die ook een plek krijgen in deze module: | |||
==== Ontwerpen en ontwikkelen ==== | |||
[[Bestand:Vaardigheden1.png|400px]] | |||
==== Informatica hanteren als perspectief ==== | |||
[[Bestand:Vaardigheden2.png|400px]] | |||
==== Samenwerken en interdisciplinariteit ==== | |||
[[Bestand:Vaardigheden3.png|400px]] | |||
=== Skill-tree Physical Computing === | |||
De leerdoelen zijn uitgewerkt in de skill-trees voor de drie submodules: | |||
[https://drive.google.com/open?id=1_Yu9JUw-_EqbAn3MJIptgZmJz0M1VpzFl6vXweyxIw0 Opbouw en leerdoelen submodule 1] | |||
[https://drive.google.com/open?id=1804QzMcXnbdfh--nlDww1ouJffCPoHWG6z8YHIq_cvE Opbouw en leerdoelen submodule 2] | |||
[ | [https://drive.google.com/open?id=1nThr6yo6ckzXyJ_a-PZ6uLW7ReOWpXavniRlFWZzCtc Opbouw en leerdoelen submodule 3] | ||
=== Concepten === | |||
Onderstaande overzicht toont de concepten die worden behandeld in de module. | |||
Overzicht van de belangrijkste concepten van de module: [https://docs.google.com/document/d/1Rjg3CUJ1f7rkoYEJvcmM_vkNPlPH46Qp1IOorhAkpyo/edit?usp=sharing Concepten Physical Computing] | |||
[[Bestand:Concepten.png|400px]] | |||
=== Werkwijzen en vaardigheden === | |||
Onderstaande overzicht toont de werkwijzen en vaardigheden die een plek hebben in de module. | |||
[[Bestand:werkwijzen.png|400px]] | |||
[[Bestand: | |||
=== Relaties met het kernprogramma === | |||
De stof uit het kernprogramma wordt als basis verondersteld. Hieronder staat een globaal overzicht van de relaties met het kernprogramma. | |||
* Domein B (Grondslagen): Specifiek de stof uit B3: Eindige Automaten is belangrijk. In deze module moeten de leerlingen zelf een toestandsdiagram kunnen maken en de correctheid ervan kunnen bepalen. Op die manier kunnen ze een algoritme (B1) ontwerpen. | |||
* Domein C (Informatie): Specifiek is gegevensrepresentatie belangrijk: hoe worden gegevens verkregen uit sensoren gerepresenteerd. | |||
* Domein D (Programmeren): Leerlingen moeten een toestandsdiagram kunnen vertalen naar een programma. De basiselementen van programmeren worden daarbij als voorkennis beschouwd. Het debuggen krijgt bij physical computing relatief veel aandacht vanwege de foutgevoeligheid. | |||
* Domein E (Architectuur): Specifiek de hardwarelaag in de vorm van sensoren en actuatoren, de vertaling tussen digitaal en analoog, en de rol van de micro-controller zijn van belang. | |||
* Domein F (Interactie): Specifiek de interface tussen gebruiker en systeem als ook de maatschappelijke aspecten zijn van toepassing voor deze module. | |||
=== | === Eerdere versies === | ||
[[ | [[/Leerdoelen archief]] | ||
== | == Externe bronnen == | ||
[[ | Kijk bij [[/Externe bronnen physical computing]] voor een overzicht van bronnen die we in de loop van het project hebben gevonden. |
Huidige versie van 17 jan 2018 om 15:05
Opzet en resultaten
Physical Computing is een rijk onderwerp. De mogelijke toepassingen zijn enorm. In de krant is regelmatig iets te lezen over robotica, zelfrijdende auto's, zorgrobots, smart cities, etc). En de beschikbaarheid van goedkope hardware maakt het mogelijk om de leerlingen zelf systemen te laten bouwen.
Enkele uitgangspunten:
- We willen laten zien wat toepassingen zijn van physical computing in de wereld om ons heen. Denk aan toepassingen in de zorg, transport, medische wereld, veiligheid, etc. Daarmee willen we een brede groep leerlingen aanspreken.
- We laten zien dat het voor de leerlingen heel goed haalbaar is om zelf zo'n systeem te ontwikkelen aan de hand van diverse voorbeelden (waaronder ook kunstzinnige/creatieve systemen).
- We willen dat de leerlingen zelf een systeem of prototype ontwerpen en ontwikkelen. Daarbij zijn werkwijzen als iteratief werken, samenwerken en evalueren van belang. Het is daarbij ook mogelijk dat de klas een samenhangend prototype ontwerpt en ontwikkelt, bijvoorbeeld rondom het thema smart-city.
- We willen dat de leerling in staat is om keuzes bij de ontwikkeling te onderbouwen, specifiek de keuzes voor de sensoren en actuatoren.
- We willen dat de leerling in staat is om een systeem te evalueren op aspecten als tijdigheid, betrouwbaarheid en functionaliteit.
- De module bestaat uit drie delen: toepassingen in de maatschappij, bouwstenen voor physical computing en zelf ontwikkelen.
- Het eerste deel van module is platform-onafhankelijk. Het platform-afhankelijke deel wordt voor drie platforms uitgewerkt: Arduino (hogere moeilijkheidsgraad, Lego-mindstorms en Micro:Bit/Blockly (lagere moeilijkheidsgraad).
- We bieden de bouwstenen aan op basis waarvan de leerling een systeem of prototype kan bouwen.
- We willen dat de leerling is staat is om een systeem te modelleren/beschrijven met behulp van toestandsdiagrammen (eindige automaten).
- Centrale begrippen zijn: physical computing, sensoren, actuatoren, betrouwbaarheid, tijdigheid, functionaliteit, automaten/toestandsdiagrammen.
De module is geen 'boek' dat van begin tot eind moet worden doorlopen. Het doel van de module is docenten en leerlingen kaders en ondersteuning bieden. We verwijzen deels naar externe bronnen. Dat betekent dat de module het volgende gaat bieden.
Leerdoelen en concepten
We maken concreet wat de docent van leerlingen moet verwachten om aan de leerdoelen van dit keuzethema te voldoen. Het gaat daarbij om enerzijds concepten en anderzijds vaardigheden. De leerdoelen en de vaardigheden uit het vernieuwde examenprogramma (http://www.slo.nl/organisatie/recentepublicaties/adviesinformatica/) vormen de basis. In de module zullen alle drie basisvaardigheden zoals beschreven in het nieuwe examenprogramma een plek krijgen. We interpreteren physical computing breder dan robotica.
Concreet resultaat module
- Lijst van concrete leerdoelen, zowel wat betreft concepten als wat betreft vaardigheden.
- Een concept-map waarin de centrale concepten en de relaties tussen deze concepten en met concepten buiten deze module staan beschreven
Verbinding tussen theorie en praktijk, open problemen
In deze module legt de leerling een verbinding tussen theorie en praktijk. De leerling leert op basis van de theorie zelf een fysiek digitaal artefact te ontwerpen en ontwikkelen en daarmee te experimenteren. Anderzijds zou het mooi zijn als de leerling ook begrip ontwikkelt door het experimenten, ontwerpen en ontwikkelen (of dat kan is echter nog weinig bewijs voor).
De grote beschikbaarheid van goedkope bordjes, sensoren, actuatoren maakt het mogelijk om de leerlingen veel zelf te laten experimenteren en ontwikkelen. De module biedt de mogelijkheid tot tinkering. Steeds in kleine stapjes iets uitproberen en ervaring opdoen en op die manier tot oplossingen komen.
De leerlingen zullen uiteindelijk op basis van een redelijk open probleem een fysiek digitaal artefact gaan ontwerpen en ontwikkelen. Slechts ter illustratie: bedenk, ontwerp en ontwikkel een systeem dat een probleem in je eigen omgeving oplost. Een automatische stofopveger, een plant-watergeef-systeem, een oefen-eend, etc. Het kan ook een prototype zijn.
Contexten
In de module worden op minstens twee manieren contexten geboden:
- De leerling leert over de mogelijkheden en beperkingen van physical computing in verschillende contexten. Soms wordt een context maar kort behandeld, op andere plekken in de module kan een context wat uitgebreider aan bod komen.
- De open problemen die de leerlingen krijgt voorgeschoteld zijn gedefinieerd vanuit een context, bijvoorbeeld vanuit de directe leefwereld van de leerlingen.
Uit: Concept-contextvenster, SLO, oktober 2013
De contexten maken dat de stof relevant wordt voor een brede groep leerlingen en kunnen de leerlingen daardoor motiveren. Daarnaast is één van de centrale vaardigheden uit het vernieuwde examenprogramma ‘informatica hanteren als perspectief’. Uit het examenprogramma: met kennis van zaken kunnen we verschijnselen in het dagelijks leven en de maatschappij duiden en redeneringen en oplossingen op waarde schatten. In een wereld waarin informatica zo in elk facet is doorgedrongen, is een dergelijke vaardigheid onontbeerlijk. De leerling kan in contexten onder meer mogelijkheden en beperkingen van digitale artefacten inschatten en beredeneren in vaktermen.
Concreet resultaat module
- Een weergave van toepassingen van physical computing in diverse contexten.
Doelgroep en voorkennis
De module is geschikt voor zowel leerlingen van de HAVO (denkende doeners) als VWO (doende denkers), maar kent onderscheid tussen beide onderwijstypen. De leerlingen kunnen uit alle vier profielen komen. We willen graag een brede groep leerlingen aanspreken met deze module. Dat doen we op verschillende manieren:
- Door verschillende contexten aan te bieden, die gerelateerd zijn aan verschillende profielen (zie hierboven)
- Door leerlingen te laten samenwerken in multidisciplinaire teams. Physical Computing en specifieker Robotica zijn domeinen waarin typisch verschillende expertises/vaardigheden samenkomen: modelleren, programmeren, ontwerpen, ontwikkelen, mens-machine-interactie, werktuigbouw, industrieel ontwerp, etc.
- Door keuzevrijheid te geven en meerdere paden te bieden binnen de module en/of keuzevrijheid te geven in de opdrachten die leerlingen oppakken.
- Door relaties met andere vakken te benoemen (zie hieronder)
We beschouwen de kennisdomeinen uit het kernprogramma als voorkennis. Alle leerlingen hebben dus al enige ervaring met Grondslagen, Informatie, Programmeren, Architectuur en Interactie.
Relaties met andere vakken en met andere domeinen binnen informatica
Indien de inhoud dat vereist wordt een relatie gelegd met andere vakgebieden. Het ligt bijvoorbeeld voor de hand om bij het behandelen van sensoren en actuatoren het concept spanning uit de natuurkunde te behandelen. We hebben echter niet als vooropgezet doel om concepten uit andere vakgebieden te integreren in deze module. Wel ligt het voor de hand om contexten uit andere vakgebieden te gebruiken (zie contexten). Denk bijvoorbeeld aan het programma ‘Spy in the Wild’, waarin robots worden gebruikt om dieren in het wild te observeren en zelfs het gedrag te beïnvloeden. Ook bij vakken als kunst, economie, wiskunde, filosofie en maatschappijwetenschappen liggen mogelijkheden voor contexten. De relaties met andere domeinen uit het vak informatica zijn er veelvuldig, zowel uit het kernprogramma als de keuzemodules. Die maken we zo veel mogelijk expliciet.
Concreet resultaat module
- Relaties met andere vakgebieden expliciteren
- Relaties met andere domeinen binnen het informaticacurriculum expliciteren
Opzet module
De module bestaat uit drie hoofdcomponenten:
1. Een reeks cases. Daarin worden binnen een context de toepassingen van physical computing getoond en behandeld. Deze toepassingen worden vanuit meerdere kanten geanalyseerd door de leerlingen, aan de hand van onder meer de volgende vragen:
- Welke sensoren en actuatoren worden hier gebruikt?
- Wat is de werking van het systeem, daarbij de sensoren en actuatoren in acht nemend, en nadruk op tijdigheid, betrouwbaarheid en functionaliteit.
- Wat zijn de beperkingen van het systeem?
- Wat zijn de maatschappelijke consequenties?
Deze vragen moeten worden aangevuld en aangescherpt, op basis van de precieze leerdoelen die nog moeten worden geformuleerd. De reeks cases laten zien wat de state-of-the-art is ten aanzien van physical computing en waar de huidige uitdagingen liggen. Wellicht dat de leerlingen hier al kunnen kiezen uit verschillende cases.
2. Een reeks gesloten opdrachten waarbij leerlingen een fysiek digitaal artefact moeten nabouwen. Ze leren hierbij welke bouwstenen beschikbaar zijn en hoe je die kunt combineren. Het legt de basis voor het derde hoofdcomponent (zie hieronder). De leerlingen kunnen kiezen uit verschillende opdrachten.
3. Een reeks open problemen waarbij leerlingen een fysiek digitaal artefact moeten ontwerpen en ontwikkelen om tot een oplossing te komen. Dit kan ook het ontwikkelen van een kunstobject zijn. Leerlingen werken in teams aan één van deze problemen. De leerlingen kunnen hierbij kiezen uit verschillende opdrachten en wellicht ook zelf een opdracht aandragen, bijvoorbeeld op basis van een open probleem in hun eigen leefwereld.
Concreet resultaat module
- Een reeks cases met state-of-the-art toepassingen van physical computing in verschillende contexten.
- Een reeks gesloten opdrachten waarbij leerlingen een fysiek digitaal artefact moeten nabouwen.
- Een reeks open problemen waarbij leerlingen een fysiek digitaal artefact moeten ontwerpen en ontwikkelen om tot een oplossing te komen.
Omvang
Het lesmateriaal kan uit één of meerdere submodules bestaan van tussen de 10 en 20 SLU. De omvang van het totale lesmateriaal ligt rond de 60 SLU. Ter vergelijking, een gemiddelde NLT-module beslaat 40 SLU.
Gebruik van hardware
Arduino’s, MicroBit, Lego Mindstorms, etc, er is veel hardware verkrijgbaar. Het zou mooi zijn als de module de kaders kan bieden voor hoofdcomponent 2 zoals hierboven beschreven, zonder dat de docent verplicht wordt te kiezen voor één specifiek platform. Binnen de module werken we deze kaders op basis van drie platforms meer in detail uit voor hoofdcomponent 2 hierboven. Docenten die kiezen voor een ander platform krijgen daarmee die ruimte. Docenten die meer houvast willen vinden die in de specifiek uitwerking.
Concreet resultaat module
- Overzicht van benodigde materialen voor één of twee hardware platforms, inclusief verkrijgbaarheid, kosten, etc.
- Uitwerking van de kaders voor hoofdcomponent 2 op basis van één of twee van deze hardware platforms.
Beoordelingsinstrumenten
Voor de hoofdcomponenten één en twee worden voorbeelduitwerkingen beschreven. Daarnaast leveren we voor alle drie hoofdcomponenten beoordelingsinstrumenten aan de hand waarvan de docent het proces en de producten kan beoordelen.
Concreet resultaat module
- Voorbeelduitwerkingen van de opdrachten in hoofdcomponent één en twee.
- Beoordelings- en/of toetsinstrumenten voor beoordeling van het proces en de producten van leerlingen in hoofdcomponenten één, twee en drie.
Aandachtspunten voor docenten en docentenhandleiding
Wat is belangrijk om leerling op te coachen bij het experimenteren, ontwerpen en ontwikkelen? Denk bijvoorbeeld aan het belang van werken in kleine stapjes en het testen van tussenoplossingen. Waar liggen misconcepten op de loer? Waar hebben leerlingen moeite mee? Wat zijn handige trucjes om effectief te kunnen werken? De module geeft allerlei aanwijzingen ter ondersteuning van de docent, op basis van eerdere ervaringen en op basis van testresultaten.
Concreet resultaat module
- Instructies, aanwijzingen en aandachtspunten voor de docent
- Een docentenhandleiding, met daarin onder meer uitwerkingen, voorbeeldplanning, werkvormen, etc.
Bronnen en lesmateriaal
Waar het kan maken we gebruik van bestaande bronnen, bij voorkeur open bronnen. Het lesmateriaal dat speciaal wordt ontwikkeld voor deze module komt vrij beschikbaar. Het precieze licentiemodel moet nog worden bepaald, in overeenstemming met de andere modules die voor het nieuwe examenprogramma worden ontwikkeld. We publiceren het materiaal online, voor iedereen beschikbaar. We bieden een rijk aanbod met onder meer filmpjes, interactief materiaal, die maken dat de leerlingen veelal zelfstandig de kennis kunnen opdoen. Eisen aan formaat, opmaak en dergelijke zijn nog niet voorhanden.
Concreet resultaat module
- Verwijzingen naar of integreren van bestaande bronnen voor leerlingen.
- Waar nodig, nieuw, online materiaal voor leerlingen, waaronder filmpjes
Gebruik van de module
We vinden het belangrijk dat de module draagvlak heeft bij docenten en dat de module veelvuldig gaat worden gebruikt in het informatica-onderwijs in Nederland. We hopen dat zowel leerlingen als docenten veel plezier halen uit het werken met deze module. We zullen daarom docenten geregeld om feedback vragen over de opzet en uitwerkingen van de module. Het is belangrijk dat de module in de onderwijspraktijk goed bruikbaar is, realistisch is dus. Daarnaast sorteren we voor op mogelijke nascholing van docenten op basis van deze module.
Concreet resultaat module
- We verzamelen en verwerken feedback van docenten en leerlingen.
- We ontwikkelen nascholing om docenten te stimuleren en faciliteren in het gebruik van de module.
Organisatie
Team
We hebben een ervaren en enthousiast team. Het team bestaat uit de volgende mensen.
Naam | Rol en expertise |
---|---|
Martin Bruggink | Kartrekker voor deze module
Vakdidacticus informatica TU Delft Coördinator Bètasteunpunt Zuid-Holland Enkele lesmodules ontwikkeld zoals de NLT-module Spelen met Digitale Techniek.
|
Eelco Dijkstra | Kartrekker van de module Netwerken / Internet of Things
Veel ervaring met begeleiding van docenten vanuit het Its Academy Amsterdam. Veel ervaring met de inzet van hardware zoals Arduino, MicroBit, etc. Initiatiefnemer van ICT in de wolken.
|
Hans Konings | Docent informatica Joke Smit College
|
Remie Woudt | Docent informatica RSG Broklede in Breukelen.
Veel ervaring met de inzet van Arduino en dergelijke in de klas. Heeft veel materiaal ontwikkelt en gepubliceerd op http://doc-type.nl/ |
Leen de Gelder | Docent informatica GSR Rotterdam & Beleidsmedewerker ICT.
Veel ervaring met onder meer de inzet van Lego Mindstorms in de klas. |
Verder zijn betrokken:
- John Val, docent informatica bij het Rijnlands Lyceum Oegstgeest
- René van der Veen, docent informatica bij Augustinus College
- Heleen van der Zaag, volgt de lerarenopleiding Utwente en daarbij de master Human Media Interaction.
Vanuit het landelijk overleg is de voorkeur uitgesproken om kort-cyclisch te werken. Dat betekent dat we al snel een volledige module willen opleveren, die beperkt is in omvang, maar wel volledig, inclusief docentenhandleiding en alle vereiste materialen. De eerste oplevering zal al december 2017 zijn (zie planning). De resultaten vanuit de verschillende thema-teams worden vervolgens met elkaar gedeeld en besproken. Op die manier bepalen we gezamenlijk, samen met de andere teams en het regiegroep, of we op de goede weg zijn. De samenhang en overlap tussen de modules kunnen we op die manier ook monitoren. Daarnaast is het belangrijk om feedback te ontvangen van docenten en leerlingen op de producten die we ontwikkelen en deze ook waar het kan te testen in de klas. Ook feedback vanuit inhoudelijke en didactische experts is belangrijk.
We maken zoveel mogelijk gebruik van deze Wiki die is opgezet door Eelco om met elkaar uit te wisselen.
Planning
Hieronder staat een globale planning. De eerste versie die in december moet worden opgeleverd kan bijvoorbeeld bestaat uit een minimale variant, waarin minstens één uitwerking (maak kan ook meer) van elk van de drie hoofdcomponenten is opgenomen, inclusief docentenhandleiding, etc. Vervolgens breiden we de module uit door uitwerkingen in elk van de drie hoofdcomponenten toe te voegen.
Periode | Resultaten en activiteiten |
---|---|
September 2017 – December 2017 | Ontwikkeling eerste versie module |
December 2017 | Oplevering eerste versie van een deelmodule, volledig testbaar, dus inclusief docentmaterialen, etc |
Januari 2018 – April 2018 | Testen eerste versie
Ontwikkeling / Uitbreiding van (deel)module + Verwerken eerste testresultaten
|
April 2018 | Oplevering tweede versie module, volledig testbaar, dus inclusief docentmaterialen, etc |
April – september 2018 | Testen tweede versie
Ontwikkeling / Uitbreiding van (deel)module + Verwerken tweede testresultaten
|
September 2018 | Oplevering derde versie module |
September 2018 – November 2018 | Testen derde versie module
Verwerken derde testresultaten
|
September 2018 – December 2018 | Opzet en eerste implementatie nascholing |
December 2018 | Oplevering definitieve versie module |
Voorjaar 2019 | Implementatie Tweede nascholing |
Bijeenkomsten
Datum | Locatie |
---|---|
/Woensdag 6 september van 15.00 - 18.00 | SLO Overvecht |
/Woensdag 13 sep van 17.00 – 18.00 | Via Skype |
/Dinsdag 19 sep van 20.00 – 21.00 | Via Skype |
/Woensdag 20 sep van 15.00 – 18.00 | Kick-off in Utrecht https://events.slo.nl/event/kick-off-bijeenkomst-informatica |
/Maandag 25 sep van 20.00 – 21.00 | Via Skype |
/Donderdag 5 okt van 16.00 – 18.30 | in de buurt van station Breukel |
/Woensdag 11 okt van 17.00 – 18.00 | Geannuleerd |
/Donderdag 26 okt van 16.00 – 18.30 | in de buurt van Utrecht CS |
/Woensdag 1 nov van 17.00 – 18.00 | Via Skype |
/Woensdag 8 nov van 17.00 – 18.00 | Via Skype |
/Donderdag 16 nov van 16.00 – 18.30 | in de buurt van Utrecht CS |
/Woensdag 22 nov van 17.00 – 18.00 | Via Skype |
/Woensdag 29 nov van 17.00 – 18.00 | Via Skype |
/Woensdag 6 dec van 16.00 – 18.30 | in de buurt van Utrecht CS |
/Woensdag 13 dec van 17.00 – 18.00 | Via Skype |
/Woensdag 20 dec van 17.00 – 18.00 | Via Skype |
/Donderdag 11 jan van 16.00 – 18.30 | in de buurt van Utrecht CS |
Concepten, leerdoelen en vaardigheden
Eindexamenprogramma
De basis is het nieuwe eindexamenprogramma:
In het nieuwe examenprogramma worden drie vaardigheden uitgelicht, die ook een plek krijgen in deze module:
Ontwerpen en ontwikkelen
Informatica hanteren als perspectief
Samenwerken en interdisciplinariteit
Skill-tree Physical Computing
De leerdoelen zijn uitgewerkt in de skill-trees voor de drie submodules:
Opbouw en leerdoelen submodule 1
Opbouw en leerdoelen submodule 2
Opbouw en leerdoelen submodule 3
Concepten
Onderstaande overzicht toont de concepten die worden behandeld in de module.
Overzicht van de belangrijkste concepten van de module: Concepten Physical Computing
Werkwijzen en vaardigheden
Onderstaande overzicht toont de werkwijzen en vaardigheden die een plek hebben in de module.
Relaties met het kernprogramma
De stof uit het kernprogramma wordt als basis verondersteld. Hieronder staat een globaal overzicht van de relaties met het kernprogramma.
- Domein B (Grondslagen): Specifiek de stof uit B3: Eindige Automaten is belangrijk. In deze module moeten de leerlingen zelf een toestandsdiagram kunnen maken en de correctheid ervan kunnen bepalen. Op die manier kunnen ze een algoritme (B1) ontwerpen.
- Domein C (Informatie): Specifiek is gegevensrepresentatie belangrijk: hoe worden gegevens verkregen uit sensoren gerepresenteerd.
- Domein D (Programmeren): Leerlingen moeten een toestandsdiagram kunnen vertalen naar een programma. De basiselementen van programmeren worden daarbij als voorkennis beschouwd. Het debuggen krijgt bij physical computing relatief veel aandacht vanwege de foutgevoeligheid.
- Domein E (Architectuur): Specifiek de hardwarelaag in de vorm van sensoren en actuatoren, de vertaling tussen digitaal en analoog, en de rol van de micro-controller zijn van belang.
- Domein F (Interactie): Specifiek de interface tussen gebruiker en systeem als ook de maatschappelijke aspecten zijn van toepassing voor deze module.
Eerdere versies
Externe bronnen
Kijk bij /Externe bronnen physical computing voor een overzicht van bronnen die we in de loop van het project hebben gevonden.