roosterwijs/PLAN.md

Plan – Roostersoftware Speciaal Onderwijs

Modulair, flexibel roostersysteem voor het speciaal onderwijs. Kleine aantallen, veel flexibiliteit per leerling, groep, subgroep, leerkracht en ondersteuner.

1. Uitgangspunten

• Type: webapplicatie (browser, werkt op pc en tablet).
• Bouw: Claude bouwt het leeuwendeel; jij stuurt, test en geeft richting.
• MVP-focus: (1) basisroostering, (2) flexibiliteit & uitzonderingen, (3) conflictdetectie.
• Schaal: één school, kleine aantallen — dus eenvoud boven complexe infrastructuur, maar het datamodel moet de flexibiliteit echt aankunnen.

2. Kernidee: het rooster als bouwstenen

De kracht voor speciaal onderwijs zit in modulariteit. In plaats van één vast groepsrooster bouwen we het rooster op uit losse roosterblokken die je aan wie dan ook kunt koppelen. Een blok = "wie doet wat, wanneer, waar, met wie".

Een blok kan toegewezen worden aan:

• een hele groep,
• een subgroep (deel van een groep),
• een individuele leerling (afwijking van het groepsrooster),
• met daaraan gekoppeld één of meer leerkrachten en/of ondersteuners.

Het rooster van een individuele leerling is dan: het groepsrooster plus/min zijn persoonlijke uitzonderingen. Zo houd je kleine aantallen overzichtelijk én volledig flexibel.

3. Datamodel (de modules)

Onafhankelijke, herbruikbare entiteiten:

• Persoon – basis voor leerling, leerkracht, ondersteuner (één tabel, met rol/type).
  • Leerling: hoort bij een groep, kan in subgroepen zitten.
  • Leerkracht / Praktijkondersteuner / Klassenondersteuner: inzetbaarheid, beschikbaarheid.
• Groep – klas; bevat leerlingen.
• Subgroep – flexibele deelverzameling van leerlingen (bv. niveaugroepje rekenen), kan groep-overstijgend zijn.
• Activiteit/Vak – wat er gedaan wordt (rekenen, gym, therapie, pauze…).
• Locatie – lokaal/ruimte (optioneel maar handig voor conflictdetectie).
• Tijdslot – dag + begin/eindtijd. We werken met vaste schooltijden (een instelbaar dagritme), maar tijdslots blijven aanpasbaar.
• Roosterblok – de spil: koppelt activiteit + tijdslot + doelgroep (groep/subgroep/leerling) + begeleiders + locatie.
• Uitzondering – afwijking voor een individu of dag (afwezigheid, vervanging, eenmalige wijziging).
• Schooljaar / Kalender – jaaroverzicht met studiedagen, vrije dagen en vakanties. Een vrije/vakantiedag schakelt automatisch de roosterblokken op die dag uit, zodat het weekrooster en het jaaroverzicht altijd kloppen.

Modulair betekent: elke entiteit staat los en is later uitbreidbaar (bv. ouders, vervoer, doelen/handelingsplan) zonder de kern te herbouwen.

4. Conflictdetectie

Bij het plaatsen/wijzigen van een blok controleert het systeem automatisch op:

• Dubbele inzet leerkracht/ondersteuner – staat iemand op twee plekken tegelijk.
• Dubbele inzet leerling – zit een leerling in twee blokken op hetzelfde moment.
• Locatiebotsing – twee blokken in dezelfde ruimte tegelijk.
• Onderbezetting – blok zonder begeleider (waarschuwing, niet blokkerend).

Conflicten tonen we als duidelijke waarschuwingen; jij beslist of het mag.

5. Technische opzet

• Backend: Django (Python) met Django REST Framework. Django's "apps" vormen ons modulesysteem: elke functie is een losse, in-/uitschakelbare app.
• Frontend: React – het roosterraster en de schermen.
• Database: SQLite om te starten (geen serverbeheer); later 1-op-1 te upgraden naar PostgreSQL.
• Auth/rechten: Django's ingebouwde gebruikers- en rechtensysteem (basis aanwezig, volledig uitgerold in de multi-user-module).
• Draaien: lokaal te starten; later te hosten op een eenvoudige server of clouddienst.

5b. Modulaire architectuur — een echt plugin-framework (verkoopargument)

Modulariteit is een verkoopargument: een school koopt de kern en schakelt naar wens modules bij. Modules moeten daarom écht aan/uit te zetten zijn — niet alleen nette code, maar instelbaar per school via een beheerscherm.

Het plugin-framework (onderdeel van de kern):

• Moduleregister – elke module meldt zichzelf aan met naam, beschrijving, versie en afhankelijkheden.
• Aan/uit per school – een beheerder zet modules in een beheerscherm in of uit; uitgeschakelde modules zijn onzichtbaar (geen menu's, geen schermen, geen API).
• Vaste aanhechtpunten (hooks) – de kern biedt nette uitbreidpunten (menu, schermen, rooster-acties, exports) waar een module zich op aanhaakt, zónder de kern te wijzigen.
• Afhankelijkheden & licenties – het register bewaakt afhankelijkheden tussen modules en biedt een haak voor licenties/feature-flags, zodat modules per school verkocht en geactiveerd kunnen worden.

Zo kun je het product gelaagd aanbieden: iedereen krijgt de kern, en modules als printen, ouderportaal of multi-user zijn losse, activeerbare uitbreidingen.

Kern (altijd aan): personen, groepen, subgroepen, activiteiten, locaties, tijdslots, roosterblokken, schooljaar/kalender, conflictdetectie + het plugin-framework zelf.

Modules (in-/uitschakelbaar per school):

• Printen/Exporteren – roosters als PDF/print, per groep/leerling/leerkracht.
• Multi-user & toegang – inloggen met rollen: leerling, ouder, leerkracht, ondersteuner en diverse lagen collega's (bv. directie, administratie), elk met eigen rechten en weergave.
• (later mogelijk) ouderportaal, vervoer, doelen/handelingsplan, meldingen.

6. Gefaseerde aanpak

Fase 0 – Fundament + plugin-framework Django-project, React-frontend, database, basis-UI-skelet én het plugin-framework: moduleregister, aan/uit-beheerscherm en uitbreidpunten. Dit framework is de ruggengraat van het verkoopargument, dus het komt meteen in fase 0.

Fase 1 – Basisgegevens (CRUD) Personen (leerlingen, leerkrachten, ondersteuners), groepen, subgroepen, activiteiten, locaties invoeren en beheren.

Fase 2 – Schooljaar & roostering Schooljaarkalender (studiedagen/vrije dagen/vakanties) + roosterblokken toewijzen aan groep/subgroep/leerling met begeleiders. Weekrooster tonen per groep, per leerling en per leerkracht.

Fase 3 – Flexibiliteit & uitzonderingen Individuele afwijkingen, subgroep-roosters, afwezigheid/vervanging. Leerlingrooster = groepsrooster + uitzonderingen. Vrije/vakantiedagen schakelen blokken automatisch uit.

Fase 4 – Conflictdetectie Automatische controle bij plaatsen/wijzigen, met heldere waarschuwingen.

Fase 5 – Module: Printen/Exporteren Eerste echte losse module — roosters als PDF/print, per groep/leerling/leerkracht.

Fase 6 – Module: Multi-user & toegang Inloggen met rollen (leerling, ouder, leerkracht, ondersteuner, collega-lagen), elk met eigen rechten en weergave.

Na elke fase heb je een werkende versie die je kunt uitproberen; we passen aan op basis van wat je ziet. De modules (fase 5–6) bewijzen meteen dat de modulaire opzet werkt.

7. Beslissingen (vastgelegd)

• Techstack: Django (backend, modules via apps) + React (frontend) + SQLite → later PostgreSQL.
• Tijden: vaste schooltijden, plus een jaaroverzicht met studiedagen, vrije dagen en vakanties.
• Locaties: meenemen in de MVP (ook voor conflictdetectie).
• Multi-user: niet in de MVP, maar als losse module gebouwd (leerling-, ouder- en gelaagde collega-logins).
• Modulariteit: een echt plugin-framework als verkoopargument — modules per school in-/uitschakelbaar via een beheerscherm, met haak voor licenties. Komt al in fase 0.

8. Volgende stap

Ik start met Fase 0: Django-project met modulestructuur, React-frontend en database opzetten — zodat we snel een werkend skelet hebben om op verder te bouwen. Zeg het woord en ik begin.