• Mondriaan
  • Over ons
  • Contact
  • Handleiding
  • Opleiding
  • Aanmelden
  • Mondriaan
  • Over ons
  • Contact
  • Handleiding
  • Opleiding
  • Aanmelden
home/Handleiding/Tips & Tricks/Flexibele lessen organiseren

Flexibele lessen organiseren

892 views 2 26 februari 2020 Updated on 19 August 2025 petervanhirtum[print-me printstyle="pom-small-grey" tag="span" target=".title-content-print"]

Flexibele lessen organiseren

We illustreren dit probleem met een geval uit de praktijk. Op het einde van de pagina kan men de voorbeeldbestanden vinden die gebruikt werden om dit probleem te illustreren.

Probleemstelling

In de eerste graad hebben we 3 parallel klassen 1A1, 1A2, 1A3 die elk 32 uur les organiseren per week. De lessen moeten als volgt georganiseerd worden:

  • 12 uur: vaste vakken die alle leerlingen moeten volgen (AAR, GES, TECHN, LO, PRAKT, GODS, FLX_TIT). Klassen zitten apart.
  • 4 uur: te kiezen optie uit 3 vakken (STEM, SPORT, LAB). Klassen zitten apart.
  • 16 uur: flexibel in te plannen algemene vakken (WIS, NAT, NED, FRA, ENG). Klassen zitten samen.

De 4 uur optie vakken is een klassieke opdeling die in principe op voorhand vastgelegd wordt door elke leerling. Een leerling die bijvoorbeeld de optie STEM kiest zal elke week 4 uur STEM krijgen en nooit SPORT of LAB volgen. Om dergelijke lessen in het rooster te plannen wordt klassiek gebruik gemaakt van een partitie. De klassen 1A1, 1A2, 1A3 worden uitgebreid met bijvoorbeeld een partitie “1A_Optie” die dan de partitie-elementen STEM, SPORT, LAB krijgt. Elke leerling kan dan beslissen in welk partitie-element hij valt. De partitie-elementen (=klasdelen) worden onafhankelijk van elkaar gepland.

De 17 uur die flexibel ingepland moeten worden is het voorwerp van deze pagina:

  • In elke klas worden 16 uur in het rooster voorzien waar de flexuren gepland kunnen worden.
  • Per flexuur willen we een klas kunnen opdelen in 3 groepjes en aan elk groepje kan een andere flexles gegeven worden.
  • Voor een klas hebben we per week 16 uur * 3 groepjes = 48 flexlessen. Die 48 flexlessen worden als volgt ingevuld:
    • 12 flexlessen FLX_WIS
    • 12 flexlessen FLX_NED
    • 12 flexlessen FLX_FRA
    • 9 flexlessen FLX_NAT
    • 3 flexlessen FLX_ENG
  • In het begin van de week, vóór het moment dat de flexlessen beginnen, moet de titularis van de klas de kans krijgen om de leerlingen, voor die week, in te delen in die 48 flexlessen. De titularis gaat zal die opdeling doen op basis van de noden van elke leerling. De 48 flexlessen liggen dus vast maar wie elk van de 48 flexlessen volgt is iets wat flexibel per week en per leerling door de titularis bepaald wordt. Om die plannen te doen voorzien we één uur FLX_TIT in elke klas waarbij de titularis de planning voor de week maakt.

In volgend plaatje zien we een voorbeeldrooster voor de klas 1A1. Op het eerste uur van maandag gaat het vak FLX_TIT door voor alle leerlingen. Tijdens dit uur wordt de planning gemaakt. Op het tweede uur zien we al een voorbeeld van een flexuur waarbinnen 3 flexlessen doorgaan. De klas is duidelijk opgedeeld in 3 groepjes.

Er worden nog eisen gesteld aan dit systeem:

  • Flexuren voor 3 klassen op het zelfde moment: Omdat we tijdens de flexuren de klassen 1A1, 1A2, 1A3 steeds opdelen in 3 kleinere groepjes is het handig om in de 3 klassen dezelfde flexlessen op dezelfde momenten te organiseren. Dit maakt de organisatie van die lessen veel eenvoudiger. Als de 3 klassen allemaal op het 2de uur van maandag de 3 zelfde flexlessen hebben dan hoeven we per flexles maar 1 leerkracht te voorzien (bijvoorbeeld INGE voor FLX_NED) en dan kunnen de leerlingen van 1A1, 1A2, en 1A3 die FLX_NED moeten volgen samengevoegd worden in een grotere groep.
  • Flexuren in blokken in de week: Een leerkracht die flexuren geeft zal naar alle waarschijnlijkheid een aantal van die flexuren op dezelfde dag moeten geven. Het is handig om ze dan samen te houden in blokken. Het kan ook zijn dat op sommige momenten bepaalde flexuren niet moeten doorgaan omdat er geen nood aan is. Beter dat ze dan geblokt zijn. ook voor de klassen is het handiger dat de flexuren geblokt worden. In dit voorbeeld gaan we uit van volgende blokken waarin de flexuren moeten vallen:
    • 3 blokken van 4 uur
    • 1 blok van 3 uur
    • 1 blok van 2 uur
  • Merk op dat we dan 17 uur in blokken hebben. De reden voor het extra uur is dat we ook het planningsuurtje FLX_TIT aansluitend in zo’n blok wensen te plannen.

In dit plaatje zien we 2 van de 3 klassen samen. Wat hier duidelijk te zien is, is dat de flexuren samenvallen en dat de flexuren inderdaad in die blokken gepland werden:

Voor de leerkrachten die flexuren moeten geven gaan we ook eisen dat ze niet meer dat 3 uur flexuren per dag geven. In dit plaatje zien we 2 leerkrachten die flexuren geven. AN is hier ook de titularis van 1A1.

Mogelijke oplossing voor dit probleem

Er is niet één oplossing voor problemen zoals deze. Mondriaan biedt een waaier aan basisconcepten aan die gecombineerd kunnen worden om dergelijke problemen op te lossen. basisconcepten die we kunnen gebruiken zijn o.a.:

  • Klassen opdelen in partities
  • Extra resources (varia types) opnemen om opdrachten in een bepaalde richting te duwen of te bundelen
  • Vensters om opdrachten te bundelen
  • Waarde- en volgordespreidingen
  • Zelfde roosterpunt linken om opdrachten samen te zetten

Met deze basisconcepten maken we een “design” van de oplossing en houden we rekening met volgende zaken:

  • Het berekende resultaat moet aan de functionele eisen voldoen
  • De rekentijd moet binnen de perken blijven. Dit ziet men al snel aan een schaalmodel als dit. De ene oplossing kan veel sneller berekend worden dan de andere.
  • De invoer van de data moet handig blijven.
  • De rapporten moeten bruikbaar blijven.

We zullen hier één design volledig uitwerken en gaandeweg een aantal alternatieven bespreken. Voor de grote alternatieven die besproken worden zullen achteraan ook voorbeeldbestanden geleverd worden.

De vaste en de optie uren

Voor de klas 1A1 (zelfde patroon voor andere klassen) hebben we in het opdrachten tabblad de 12 vaste uren rood omkaderd en de 4 optie-uren in het geel gezet. De vaste uren zijn klassiek. De vakken worden apart gegeven, geen samenzettingen. Voor de optie-uren (STEM, SPORT, LAB) maken we gebruik van een partitie. De klas 1A1 heeft een partitie 1A_Optie met partitie-elementen STEM, SPORT en LAB. Voor elk partitie-element plannen we een aparte opdracht van 4 uur met hun respectievelijke vakken, leerkrachten en lokalen.

Merk op dat partitie-elementen (=klasdelen) van dezelfde partitie en klas perfect op dezelfde plaats in het rooster kunnen staan. De reden hiervoor is dat ze per definitie disjunct zijn (Een leerling kan maar in 1 partitie-element van dezelfde partitie zitten dus een overlap kan er niet zijn. Dit in tegenstelling tot partitie-elementen van verschillende partities van dezelfde klas, die uit voorzorg als niet disjunct behandeld worden en dus nooit op dezelfde plaats kunnen staan). Echter, het is niet per definitie zo dat de partitie-elementen van 1A_Optie op dezelfde plaats staan, ze kunnen perfect op andere uren staan. In het geval van 1A_Optie willen we toch graag dat alle leerlingen tegelijkertijd hun optievakken hebben. We kunnen dit forceren door de 3 opdrachten te verbinden via een ZR-Link. In de kolom ZR-Link zien we ZR000 staan. Deze gaat ervoor zorgen dat de optie-vakken gelijktijdig gepland worden. Van elk van de 3 optie-vakken hebben we 2 blokken van 2 uur. Door de ZR-Link gaan telkens 3 blokken van 2 uur samenvallen. In het rooster van 1A1 zien we dat die per 3 samen staan op woensdag 3 en vrijdag 6. Voor 1A2 liggen ze op dinsdag 6 en donderdag 5.

De partitie 1A_Optie is als volgt gedefinieerd voor elke klas:

Andere manieren om die 1A_Optie blokken gelijktijdig te plannen (achtergrondinformatie):

  • Stel dat we een rooster van 32 uur hebben en dat er reeds 28 uur gevuld zijn door andere vakken. Er schiet nog 4 uur over en het enige wat nog gepland moet worden zijn de optie-vakken. In dat geval kunnen die niet anders dan in dat gat van 4 uur vallen. Omdat partitie-elementen van dezelfde partitie elkaar niet in de weg zitten (op voorwaarde dat ze geen resources delen) gaan die 6 blokken van 2 uur zich dus perfect in dat gat van 4 kunnen nestelen. In dit geval is het in theorie niet nodig om een ZR-link te gebruiken. Het is echter handig om het wel te doen. We weten dat ze samen moeten gepland worden. Er is dan ook geen reden om daar onnodig rekenkracht aan te verspillen om uit te vinden dat het niet anders kan dan samen te staan.
  • In plaats van een ZR-link kan men bijvoorbeeld ook 2 keer 3 parallelle vensters van 2 uur gebruiken om ze samen te zetten. Men moet de opdrachten dan wel opsplitsen in 2 opdrachten van 2 uur of met vensters in of-takken werken. Dit is onnodig complex maar wel mogelijk. (Merk trouwens op dat een van de implementaties (achter de schermen) van een ZR-Link net bestaat uit een oplossing met parallelle vensters).
  • Ook via extra resources (varia types) kan men opdrachten samendrijven.

De flexibele uren

Na deze nuttige informatie over het plannen van de optie-vakken komen we hier tot het echte probleem: het plannen van de flexuren.

We gaan het probleem via een partitie oplossen maar we wijken hier wel wat af van het klassieke gebruik ervan. We hebben 5 vakken die in de flexlessen gegeven moeten worden. We kunnen voor elke klas de partitie 1A_Flex definiëren met telkens de 5 partitie-elementen die de vakken voorstellen die in de flexlessen gegeven moeten worden. In het tabblad van de klassen ziet dat er als volgt uit:

Alhoewel we de klas nu in theorie op elk moment in 5 kunnen splitsen en aan elk van die 5 klasdelen apart les kunnen geven is dat hier NIET de bedoeling. Wat we willen bereiken is dat we voor klas 1A1 op elk flexuur de klas in 3 kunnen splitsen en dat er aan 3 groepjes lesgegeven kan worden, niet aan 5 groepjes. Wat we echter niet op voorhand willen/kunnen beslissen is welke opdeling we op elk flexuur maken. De ene keer kan het FRA/NED/ENG zijn, de andere keer WIS/ENG/FRA enz. We willen het systeem zelf laten beslissen welke combinatie van 3 flexlessen er op elk flexuur kan staan. We zien verder hoe wat dat kunnen afdwingen. Herinner u dat we 48 flexlessen gaan plannen voor elke klas en dat we dat dus gaan organiseren op 16 uur. 16 uur * 3 groepjes = 48 flexlessen. Het resultaat moet dus zijn dat er telkens exact 3 flexlessen doorgaan op elke flexuur. Als we geen beperking opleggen dan kan het zijn dat er op 1 flexuur 5 flexlessen vallen en op een ander flexuur maar 1 flexles, of zelfs helemaal geen.

Waar wijken we nu af van het klassieke gebruik van partities? Voor een klassieke partitie is de opdeling van de leerlingen in partitie-elementen statisch bepaald, op voorhand vastgelegd. Elke leerling is toegewezen aan een patitie-element en elk partitie-element bevat minstens 1 leerling. Dat is bijvoorbeeld zo voor 1A_Optie. Voor 1A_Flex is dat niet zo. Voor elk flexuur gaan we de leerlingen van de klas verdelen over 3 partitie-elementen en de andere 2 zijn dan per definitie leeg. Dus, voor elk flexuur zullen de leerlingen verdeeld worden over de partie-elementen die dan gepland zijn in het rooster, de andere worden niet gebruikt. Dat is dus een dynamische planning. Men zal dan ook een waarschuwing zien bij de klas die zegt dat we niet elk partitie-element evenveel uur plannen. Dat klopt inderdaad maar dat is geen probleem.

Op basis van de partitie-elementen, het aantal uur dat van elke flexles gegeven moet worden, het feit dat de flexlessen voor 1A1, 1A2, 1A3 moeten samenvallen, kunnen we dat naar opdrachten vertalen op de volgende manier:

Het vak FLX_FRA wordt steeds door ILSE gegeven aan het partitie-element FLEX_FRA voor elk van de 3 klassen tegelijk en dat voor 12 losse uurtjes. Voor de andere flexlessen ziet men ook de juiste aantallen. In totaal 48 uur. Stel dat we verder niets doen en dit geheel even plannen. Het resultaat zou er dan als volgt kunnen uitzien:

Er wordt aan een heel aantal voorwaarden nog niet voldaan. Enkele voorbeelden van zaken die niet goed zijn:

  • Er wordt maar op 13 uur flexlessen gegeven en niet op de geplande 16 uur, er zijn 3 uur zonder les.
  • Niet op elk gebruikt flexuur staan 3 flexlessen gepland. Sommige hebben er 5, 4, 2 en zelfs 1.
  • Er zijn leerkrachten die meer dan 3 uur flexlessen per dag geven.
  • Het planningsuur FLX_TIT ligt toevallig voor de flexuren maar had er ook midden in of na kunnen liggen. het sluit ook niet aan.
  • De flexlessen zijn niet in blokken gepland.

We lossen eerst het probleem op van het aantal flexlessen per uur op. Dit gaan we doen via een waardespreiding. Omdat het over klassen gaat die in partities opgedeeld zijn komen we nog een interessante complexiteit tegen waar we rekening mee moeten houden bij waardespreidingen.

Wat we willen kunnen uitdrukken in een waardespreiding is dat het aantal flexlessen op elk uur van de week niet meer dan 3 mag zijn. Dus, voor een willekeurig uur tellen we het aantal flexlessen (opdrachten) die daar gepland zijn en dat mag niet groter dan 3 zijn. Door dit max van 3 te stellen zorgen we voor een mooie verdeling over de 16 flexuren. De vraag is hoe we die opdrachten in de waardespreiding gaan selecteren. Laat ons eerst naar een correcte oplossing kijken.

We selecteren de opdrachten op basis van een custom kolom (vlagje) “FLEX” die in het opdrachten tabblad aangemaakt werd. In deze kolom hebben we de opdrachten aangeduid die flexlessen zijn. Met deze spreiding actief plannen we opnieuw:

Dit lost inderdaad het probleem op, er zijn nu exact 3 flexlessen per flexuur gepland. Merk op de ELK_UUR een OF-uurlijst is waarin elk uurt apart vermeld wordt.

Waarom hebben we die customkolom “FLEX” nodig om de opdrachten te selecteren? Inderdaad een goede vraag. We hadden bijvoorbeeld ook gewoon de naam van de klas als selectiecriterium kunnen gebruiken. Het probleem hiermee is dat als je een klasnaam gebruikt dat dit een speciale betekenis heeft van zodra de klassen opgedeeld zijn in partities. In dat geval gaan de spreidingsregels gelden per partitie-element en niet meer voor de ganse klas. We gaan m.a.w. per partitie-element de opdrachten bekijken en de telling doen. Dat gaat natuurlijk niet het gewenste resultaat geven omdat we net alle opdrachten voor alle partitie-elementen willen samentellen op elk uur om de controle te doen. Zie de pagina “Opdrachten beperken door waardespreidingen” voor meer info over dit topic.

Wat we wel hadden kunnen doen is een opsomming maken van alle flex vakken om de spreiding uit te drukken:

Dit zou hetzelfde resultaat geven. We selecteren hier dezelfde opdrachten mee en we vermelden geen klasnamen waardoor de spreiding niet per partitie-element bekeken wordt.

Wat indien er meerdere klasgroepen zijn die elk hun eigen flex-regelingen moeten hebben? In dat geval gaan we bijvoorbeeld de FLEX kolom aanpassen en er geen vlagje maar een lijst van maken waardoor we flex-opdrachten kunnen onderverdelen in bijvoorbeeld 1A_flex, 2C_flex, etc. We kunnen die “labels” dan gebruiken in de spreidingsregels.

Het volgende probleem dat we moeten oplossen is dat van het aantal uur flexles dat leerkrachten per dag mogen geven. Kijken we nu naar het rooster van twee flex leerkrachten dan heeft die duidelijk teveel uur per dag.

Dit kunnen we eenvoudig oplossen door volgende waardespreiding (er zijn meerdere manieren om dit te doen):

We gebruiken hier weer de CC_FLEX custom kolom omdat dat nu makkelijk selecteert. In het extra selectiecriterium zetten we de groep LKR_FLEX. Dat is gewoon een groep van de 5 leerkrachten die in het flexsysteem zitten. Via deze constructie zal voor elk van de 5 leerkrachten de spreiding apart gecontroleerd worden. het resultaat:

Nu zijn er max 3 flexlessen per dag voor elke leerkracht. Merk op dat de uurlijst ELKE_DAG een OF-uurlijst is die de uren van elke dag van de week opsomt in 5 lijstjes. Per dag worden de flexuren dan geteld. We zien voor AN dat er ook het FLX_TIT uur op de rooster staat. Deze hebben we niet opgenomen als flexuur in de spreiding. We zouden dit ook kunnen doen als dat nodig is maar omdat het over de planning zelf gaat van de flexlessen en niet zozeer over de flexlessen zelf hebben we die erbuiten gehouden.

Wat ook duidelijk nog niet klopt is dat het planningsuur (FLX_TIT) niet vóór de flexlessen zelf staan.

We kunnen een volgordespreiding gebruiken om het planningsuur voor de titularis vóór de flexuren in de respectievelijke klas te krijgen. Dat kan op volgende manier:

Kijken we naar titularis AN dan zien we dat alle opdrachten waarin FLX_TIT én AN voorkomen gepland moeten worden vóór alle opdrachten die het label CC_FLEX hebben en dat binnen het interval [w1_maandag1…w1_vrijdag8].

Het resultaat voor 2 van de titularissen:

Het rooster van de klas 1A1 ziet er ondertussen als volgt uit:

Er rest nog 1 probleem dat opgelost moet worden. De flexlessen zijn helemaal nog niet in blokken gepland. In de eisen stond vermeld dat we die 16 flexuren (+1 planningsuur) in volgende blokken moesten plannen: 4, 4, 4, 3, 2. Volgend plaatje toont deze 5 blokken en hoe ze bijvoorbeeld in de week zouden kunnen geplaatst worden. We willen dat de flexuren in een dergelijk patroon vallen.

Er zijn opnieuw verschillende manier om dit op te lossen. We kunnen het niet oplossen door de flexopdrachten zelf als blokken te definiëren, elk flexuur kan tenslotte een heel andere inhoud hebben dan elk ander. Als je uren in blokken plant dan is de inhoud voor elk uur in dat blok hetzelfde. Dat helpt ons dus niet verder. We gaan dit moeten oplossen door de flexopdrachten samen te drijven in deze blokpatronen via andere constructies. Dit zijn 2 manieren om dat te doen:

  • Vensters: We kunnen vensters definiëren waarin de flexopdrachten moeten vallen. Vensters met als grootte 4, 4, 4, 3, en 2. Echter, omdat we op elk uur 3 flexopdrachten moeten plannen hebben we dus per blok 3 vensters nodig die telkens parallel liggen. We hebben 15 vensters nodig die samen de 48 + 3 gaten voorzien waarin de 48 flexlessen en de 3 planningsuurtjes moeten vallen. Elke flexopdracht krijgt dan een keuzelijst van 15 vensters. Dergelijke constructie is rekenintensief en dus niet te verkiezen indien er een betere oplossing bestaat. Bij deze vensteroplossing kunnen we wel de extra waardespreiding laten vallen die eist dat er max 3 flexlessen per flexuur gegeven mogen worden. Dat wordt automatisch opgelost via die vensters.
  • Varia resources: een beter alternatief (qua rekentijd) is het probleem aanpakken door extra variatypes te gebruiken. De redenering is als volgt:
    • We voeren 3 variatypes in (1A_flex1, 1A_flex2, 1A_flex3).
    • We maken opdrachten aan die deze 3 variatypes in blokken samenzet zoals voorgesteld in het plaatje hierboven. De 3 variatypes staan dan steeds samen in de 3 blokken van 4, 1 blok van 3 en 1 blok van 2. De opdrachten waarmee we dat doen zijn onafhankelijke opdrachten die niets anders dan de 3 variatypes bevatten. Ze leggen dus het patroon uit dat we willen bereiken. De reden waarom we 3 variatypes samen nodig hebben wordt dadelijk duidelijk.
    • Als we nu alle NIET-flex opdrachten van klas 1A1 uitbreiden met variatype 1A_flex1, die van 1A2 met 1A_flex2, en die van 1A3 met 1A_flex3 dan kunnen daardoor al deze NIET-flex opdrachten enkel plaatsen liggen waar de eerder gelegde patroonblokken NIET liggen.
    • We hebben door die variatypes de NIET-flexopdrachten in zulk een posititie gedreven dat de enige open plekken in het rooster voor de 1A klassen net de patroonblokken zijn. Als we dan de flexopdrachten plaatsen kunnen die niet anders dan in die open ruimte vallen. In de flexopdrachten zelf hoeven we dus helemaal geen variatypes meer op te nemen.
    • Deze oplossing maakt geen gebruik van of-takken en de rekentijd zal hierdoor merkelijk beter zijn dan met de vensteroplossing.

In wat volgt zullen we de versie met de variatypes verder uitwerken. De versie met de vensters wordt ook meegegeven om het verschil te kunnen zien.

In het opdrachtentabblad definiëren we de opdrachten om de 3 variatypes samen in de gewenste blokken te roosteren. Merk op dat we ook als extra nog uurlijsten opgegeven hebben waar deze blokken mogen vallen (EERSTE, w1_WOENSDAG). Kan een extra eis zijn maar hoeft niet.

Het getoonde beeld filtert op alle opdrachten waar 1A_flex1 en 1A1 inzitten. We zien dat alle NIET-flexopdrachten van 1A1 nu ook als variatype 1A_flex1 hebben.

Als we dit geheel roosteren maar we vinken de flexopdrachten nog even uit dan krijgen we voor 1A1 en 1A_flex1 de volgende mogelijke oplossing:

Wat hier mooi te zien is, is hoe het variatype 1A_flex1 plaatsen “reserveert” in het rooster van 1A1 waarin de flexopdrachten nu gepland kunnen worden. Zie ook in het 1A_flex1 rooster hoe de 3 variatypes samen geplaatst zijn in die blokken. Als we nu de flexopdrachten meeroosteren gaan die mooi in de gereserveerde ruimte vallen:

1A1 naast 1A_flex1: flexlessen vallen mooi in de gereserveerde ruimte.

1A1 naast 1A3: flexlessen van alle klassen vallen samen.

Had het nog zuiniger gekund? Ja, maar…

  • We hebben 3 variatypes ingevoerd, voor elke klas een. Maar dat is in feite niet nodig.
  • We weten dat de flexopdrachten zelf steeds hetzelfde partitie-element van de 3 klassen meenemen. Het is dus onmogelijk dat de flexlessen voor de verschillende klassen op andere momenten zouden vallen. De flexopdrachten zelf maken de koppeling tussen de 3 klassen.
  • We zouden dus in plaats van 3 variatypes ook één variatype kunnen gebruiken. Stel dat we alleen 1A_flex als variatype gebruiken. Met dit variatype maken we de blokken zoals eerder met de 3 samen en we plaatsen dit enige varitype enkel in de NIET-flexopdrachten van 1A1.
  • In dit geval gaat 1A_flex lege plaatsen reserveren in 1A1. In 1A2 en 1A3 maken we die reservaties niet. Maar, doordat de flexopdrachten enkel in de gereserveerde ruimte van 1A1 kunnen vallen moeten de klassen 1A2 en 1A3 wel volgen.

Dus, met 1 variatype kan het evengoed opgelost worden. Echter, er is een “maar” wat de rekentijd betreft. Door van 3 naar 1 variatype te gaan halen we redundantie weg maar dat is niet altijd de beste oplossing. Net door die redundantie gaat veel onnodig zoekwerk niet gebeuren. Als we de (rode) blokken reserveren dan doen we dat in het eerste geval meteen voor de 3 klassen samen en in het tweede geval enkel voor 1A1 terwijl we eigenlijk wel weten dat we dat meteen ook voor 1A2 en 1A3 moeten doen. Door de koppeling via de flexopdrachten komt dat uiteindelijk ook wel goed maar via een omweg.

Dus, in dit geval houden we beter de redundantie. Dit voorbeeld leveren we ook mee om te bekijken.

De uitgewerkte voorbeelden

Om de bestanden te gebruiken download men de zipfile en pakt men het bestand uit. Elke zipfile bevat 1 zttxml-bestand.

  • Flex 3 klassen – Partities en 3 Variatypes
  • Flex 3 klassen – Partities en 1 Variatype
  • Flex 3 klassen – Partities en Vensters
  • Flex 3 klassen – Geen Partities

Het laatste voorbeeld werd niet in de tekst besproken maar is een alternatief zonder vensters en zonder partities voor de flexlessen. Voor de 3 klassen worden gewoon 5 FLEX blokken les gepland zonder dat in het rooster van de klas te zien is welke flexlessen er op elk uur doorgaan. Die informatie kan men dan wel uit de rooster halen van de leerkrachten bijvoorbeeld. Het is ook een alternatief dat bruikbaar is.

(PS. Deze bestanden zijn te gebruiken vanaf Mondriaan versie 2020.2.0)

Print Friendly, PDF & Email

Didn't find your answer? Contact Us

  Verplaatsingen van leerkrachten en klassen beperken

time-tech
  • Mondriaan
  • Over ons
  • Contact
  • Handleiding
  • Opleiding
  • Aanmelden
Nieuwste handleidingen
  • Lessen inhalen die vervallen door stageperiodes: methode 2
  • Roosteren op leerlingenniveau
  • Kwaliteitscontrole – Springuren en Vakspreiding
  • XML-Export naar Smartschool Planner en andere systemen
Contact

Neem gerust contact op om een afspraak te maken of om een demo aan te vragen.

E-mail: info@time-tech.be

Opleidingen
Vandaag
maandag
dinsdag
woensdag
donderdag
vrijdag
zaterdag
zondag
m
d
w
d
v
z
z
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
1
2
3
4
5
  • © 2021 time-tech.be. Alle rechten voorbehouden. Privacy Policy | Cookiebeleid

Veelgezochte termen:Outputrooster, Volgordespreiding, Partitie