Projectplan
Zie ook:
Probleembeschrijving:
Docenten kunnen leslokalen en de twee gedeeltes van de mediatheek reserveren om op een bepaald tijdstip te kunnen gebruiken. Op dit moment gebeurt dat met een agenda. Er is een actueel overzicht met lokalen die op een bepaald moment vrij zijn. Als het lokaal daarop vermeld is wordt het doorgestreept en wordt de reservering in een agenda gezet. Echter, wanneer er een (dag)roosterwijziging plaatsvindt, worden de reserveringen niet gecontroleerd en blijven dus staan. Daardoor komen er twee klassen in hetzelfde lokaal en is er dus een probleem. Dit komt bij sommige lokalen, zoals het computerlokaal, om onbekende redenen zelfs wekelijks voor, zelfs als er niets aan het rooster wijzigt.
De taak is nu om een informatiesysteem te bouwen om reserveringen en zo mogelijk ook roosterwijzigingen in te kunnen voeren, waarbij reserveringen voor een lokaal en tijdstip waar al een les gepland is onmogelijk worden. Ook moet het systeem bij elke (dag)roosterwijziging controleren of er geen les verplaatst wordt naar een lokaal dat gereserveerd is. Verder is het de bedoeling dat docenten en leerlingen vanuit elke computer op school (leerlingen natuurlijk alleen vanuit het computerlokaal en de mediatheek) van te voren kunnen controleren op welke tijdstippen een lokaal al gereserveerd is en zo zelf het gunstigste tijdstip bepalen. Het is belangrijk dat de gegevens daarbij niet gewijzigd kunnen worden, dus er moet een goede beveiliging geļmplementeerd worden. Het zal alleen mogelijk zijn vanuit de computer(s) bij de conciėrge om roosterwijzigingen in te voeren.
Slechts een idee is om, na aanvraag, leerlingen en docenten per e-mail en misschien SMS over de laatste wijzigingen die hen betreffen op de hoogte te houden. Als de Linux server bij de conciėrge ook toegankelijk zal zijn vanaf buiten de school, zouden leerlingen zelfs thuis via Internet en via WAP de wijzigingen kunnen inzien.
De conciėrges zelf ondervinden niet echt last van het probleem, de leraren wel, die op het laatste moment een ander lokaal moeten zoeken bij een dubbele reservering. Als er niets aan het probleem gedaan wordt zullen de dubbele reserveringen door gaan en blijven er problemen bij docenten bestaan.
Projectaanleiding:
Het project is niet door de opdrachtgever meneer van de Broek in gang gezet, maar door de docent informatica, meneer Lemmens, wie slachtoffer was van het probleem en het nu beu was.
Projectresultaat:
De grenzen zijn op dit moment nog niet goed vast te leggen, omdat het nog niet zeker (maar wel waarschijnlijk) is dat alles uit te voeren is. Wel vast staat dat de conciėrge reserveringen in het systeem moet kunnen invoeren, wijzigen en opvragen, via een Windows programma. Verder moeten automatisch na elke lesroosterwijziging (ook elke wijziging aan het dagrooster) de reserveringen worden nagegaan. Reguliere lessen hebben voorrang op reserveringen, de reserveringen vervallen dus in een geval van een dubbele les.
Zoals al eerder vermeld is een mogelijkheid, nadat het hoofddoel is bereikt, om het project uit te breiden, zodat ook wijzigingen aan het dagrooster kunnen worden bijgehouden. Nog onwaarschijnlijker is de mogelijkheid tot het inzien van relevante wijzigingen via het intranet van de school, e-mail, Internet en ook WAP. Merk op dat de opdrachtgever dit niet noodzakelijk vindt, hoewel een centrale agenda voor alle wijzigingen en reserveringen gewenst is.
Projecteffecten:
Indien het project volgens het hierboven beschrevene kan worden voltooid, zullen er weinig negatieve gevolgen zijn. Het enige nadelige is dat conciėrges de reserveringen in de computer moeten invoeren, maar dat doen ze nu toch al gedeeltelijk.
Wel zullen er vele positieve gevolgen zijn. Zo zullen er minder problemen ontstaan bij een dubbele les, in elk geval hoeft het probleem niet meer op het laatste moment opgelost te worden. De conciėrges kunnen in tegenstelling tot voorheen wel het actuele leslokaal van een bepaalde lesgroep opzoeken wanneer een leerling verdwaald is. Wanneer de wijzigingen ook gedistribueerd kunnen worden kunnen leerlingen bij alleen maar vrije uren voor de echte lessen, thuis blijven in plaats van naar school te moeten komen om te ontdekken dat er nog lang geen les is.
Randvoorwaarden:
De opdrachtgever stelt geen specifieke opleverdatum al moet het product zo snel mogelijk gereed zijn omdat anders het probleem maar voort blijft duren. De docent stelt wel een deadline; deze ligt op 29 januari 2000. Eventueel kan het project na die datum nog uitgebreid worden, hoewel de uitbreiding buiten de beoordeling valt.
Er is geen budget voor dit project, omdat de school bezig is met de aanschaf van een nieuw professioneel administratiepakket, wat ons product waarschijnlijk overbodig zal maken. Elk teamlid zou 40 uur aan de opdracht moeten werken, waarvan al zeker ± 15 uur tijdens de lessen. Meestal zal het niet nodig zijn om van bepaalde lessen vrijgesteld te worden, als dit toch het geval zou zijn, bijvoorbeeld voor een overleg met een bepaalde persoon, dan zal dit t.z.t. moeten worden overlegd.
De teamleden zullen (en moeten) heel goed in staat zijn om dit project zelf te voltooien. De hulp van meneer Bouwens (maker van het computerprogramma Dagrooster) en meneer Lemmens (informaticadocent en domeindeskundige op het gebied van de benodigde informatie) zal echter een vereiste zijn als informatiebron. Verder kan de opdrachtgever meneer van de Broek mogelijk nog bruikbare informatie leveren.
De belangrijkste eis die wordt gesteld aan het eindproduct is dat het mogelijk wordt gemaakt om reserveringen te beheren en te vergelijken met het lesrooster. Verder moet het eenvoudig door de conciėrge (en misschien ook door anderen) gebruikt kunnen worden. Tenslotte moet het perfect beveiligd worden tegen ongeoorloofde wijzigingen.
Communicatie over de projectvoortgang vindt met de opdrachtgever plaats door middel van gesprekken (een aantal keer per maand) en met de informaticadocent door middel van een wekelijks gesprek tijdens de lessen en via e-mail wanneer nodig.
Ontwikkelomgeving:
De database zal onderhouden worden via MySQL wat op een SuSE Linux server draait, vereiste is wel dat er een computer bij de conciėrge staat die is aangesloten op het netwerk waarop ook de Linux server zich bevindt.
Schrijfopdrachten aan de database worden gegeven via een Borland/Inprise Delphi programma. Deze keuze omdat deze programmeertaal goede mogelijkheden geeft om een eenvoudig te hanteren gebruiksomgeving te maken (waarschijnlijk gaat iets soortgelijks aan de optie AutoAanvullen van Internet Explorer gebruikt worden om het invoeren van reserveringen gemakkelijk te maken).
E-mail over de roosterwijzigingen zou rechtstreeks vanuit het Delphi programma verzonden kunnen worden via de e-mail servers van Kennisnet. SMS berichten zouden door het Delphi programma verzonden kunnen worden via een gratis web SMS dienst.
Als dit gedeelte werkt, zal er getracht worden met PHP (bij voorkeur de nieuwste versie, 4.0.4pl1) een systeem te implementeren wat het mogelijk maakt om leesopdrachten aan de database te geven, vanuit elke willekeurige computer op school (en hopelijk ook buiten de school), door middel van Microsoft Internet Explorer. Dit zal met name bruikbaar zijn voor leraren zodat zij een reservering van te voren rustig kunnen plannen.
Het is echter mogelijk dat het werken met PHP te complex wordt (dit is onwaarschijnlijk omdat er slechts voor een gedeelte gebruik wordt gemaakt van PHP). Dan zal het dit laatste gedeelte met PHP worden weggelaten.