Project Plan

1: Inleiding

Dit document beschrijft de eisen die worden gesteld aan het door GiPLan te ontwikkelen systeem. Het dient als basis voor het contract met de klant en als referentie voor het projectteam.

De klant

De klant is Stichting schoolLAN uit Arnhem, gevestigd op de IJsselburcht 3. schoolLAN is een landelijke stichting die een goedkope oplossing biedt voor applicatie- en netwerkbeheer voor (basis)scholen gebruikmakend van de op die school aanwezige hardware, software en besturingssysteem.
De server draait in een Linux omgeving die Windows programmatuur kan aanbieden. De clients op dat netwerk zijn computers die in een Windows omgeving functioneren. Stichting schoolLAN biedt de mogelijkheid om per gebruiker of per computer (of combinaties daarvan) allerlei mogelijkheden in te stellen. Hierbij kan worden gedacht aan beschikbaarheid van software applicaties, snelkoppelingen, disk quota van de gebruiker en gebruikersrechten. Het netwerk/schoolLAN biedt ook de mogelijkheid tot internet toegang voor alle computers, evenals virusscan en firewall mogelijkheden aan; meer dan alleen een netwerk infrastructuur dus.

De huidige situatie

Het bestaande systeem van stichting schoolLAN is al in gebruik bij een aantal basisischolen in Nederland. De huidige functionaliteit bestaat uit ondersteunende netwerk functies. De grote tekortkoming aan het huidige systeem is op dit moment de interfacing. Alle huidige functionaliteit wordt momenteel gedaan met behulp van scripts. Hetgeen absoluut geen hoge gebruikersvriendelijkheid biedt. Wanneer men bepaalde instelling wil wijzigen moet men momenteel over voldoende kennis beschikken om een script te kunnen aanpassen. Dit kan zeker niet verwacht worden van werknemers op iedere basisschool. Wat er dus binnen het systeem duidelijk ontbreekt is een gebruikersinterface waarmee de verschillende scripts makkelijk oproepbaar zijn, en eventueel makkelijk toevoegbaar.

De opdracht

Doel van dit project is het ontwikkeling van een user-interface te versnellen, zodat de verschillende scripts, die schoolLAN aanbiedt, makkelijk oproepbaar zijn. Er moeten mogelijkheden zijn om scripts aan te roepen en eventueel nieuwe scripts toe te voegen. Voor de functionaliteit zal er gesproken worden met verschillende personen binnen schoolLAN. Dit om continu feed-back te krijgen over de wensen van de klant, omtrent het door ons te ontwikkelen produkt. Vervolgens zou er een simpel prototype gemaakt kunnen worden. Verder wordt er onderzoek gehouden op verschillende basisscholen, naar de wensen wat betreft user-interface bij de gebruikers. De verschillende wensen van de klant en gebruikers zullen tegenover elkaar afgewogen moeten worden om een gebruikersvriendelijk, realiseerbaar systeem op te bouwen.

Het is de bedoeling dat GiPLAN een raamwerk gaat opzetten waarmee andere personen en/of projecten makkelijk verder kunnen werken. In dit document worden een aantal wensen van de klant qua functionaliteit besproken. Het is niet noodzakelijk dat alle functionaliteit gemaakt wordt, het zijn meer richtlijnen. Er moet wel rekening mee gehouden worden dat die functionaliteit in de toekomst eventueel nog toevoegbaar is.

Een korte samenvatting: Het project is een aanvulling op het huidige systeem. Functionaliteit moet worden omgezet naar een gebruikersvriendelijke browser- omgeving, zodat het op meerdere platform gedraaid kan worden.

Aanpak

Wij hebben gekozen om als ontwikkelingsmethode het spriraalmodel te gebruiken. Dit houdt in dat het software proces niet als een serie achtereenvolgende activiteiten gezien wordt, maar als een spiraal. Elke 'loop' in de spiraal geeft een fase aan binnen het software proces. Zo'n 'loop' is onderverdeeld in vier sectoren:

  • Het definïeren van objectieven voor die fase;
  • Uitvoeren van een risico analyse en wanneer mogelijk ook reductie van die risico's;
  • Er wordt een keuze gemaakt met betrekking tot de invulling van het ontwikkelingsmodel, zoals bijvoorbeeld prototyping;
  • De planning van het project wordt beoordeeld, en aan de hand hiervan wordt er de keuze gemaakt om verder te gaan of niet. Tevens worden de plannen voor de volgende fase vastgesteld.

Omdat dit project verdeeld is in verschillende modulen (hapbare brokken van functionaliteit) leent het zich uitstekend voor het spiraal model. Er wordt begonnen met het uitvoeren van enkele kleine modulen om 'feeling' te krijgen met het huidige systeem van schoolLAN. Vervolgens worden de meest essentiële delen gemaakt. De modulen met de laagste prioriteit komen vervolgens als laatste aan bod. Zo kan GiPLAN na ontwikkeling van de meest belangrijke modulen feedback van de klant en gebruikers ontvangen. Aan de hand van deze feedback kunnen, waar nodig, op tijd aanpassingen gemaakt worden.

Een ontwikkelingsmodel dat zich goed leent om in dit project gebruikt te worden is evolutionary prototyping. Met dit in gedachte zou het mogelijk zijn om snel de eerste resultaten te boeken. Op deze manier wordt de klant meer betrokken bij het product en kunnen de eisen van de klant, waar nodig, nog aangepast of aangescherpt worden.

Wanneer de eisen van de gebruikers en de klant in de loop van de tijd duidelijker worden, zal het bijbehorende deel van dit document aangepast worden. Bij de opzet van dit projectplan zijn nog niet alle details van bepaalde modules helemaal duidelijk. Dit hoeft ook niet. Het voordeel van het spiraalmodel is immers dat de eisen in de loop van de tijd nog bijgesteld kunnen worden, voor de ontwikkeling van die specifieke module.

Opbouw

De rest van dit document is als volgt opgebouwd:

  • Functionele vereisten: in dit gedeelte wordt in Algemeen Beschaafd Nederlands vastgelegd wat de functionaliteit van de te bouwen interface moeten zijn;
  • Niet-functionele vereisten: eisen aan het programma, die niet direct met de functionaliteit te maken hebben;

2: Functionele vereisten

Inleiding

In dit deel van het projectplan wordt beschreven wat de functionaliteiten van het systeem zijn.

Interface

De interface is een visueel hulpmiddel om scripts toe te voegen, te verwijderen, of bepaalde instellingen en voorkeuren aan te kunnen passen. Voor de user-interface wordt gebruik gemaakt van een webbased interface. Op deze manier kunnen de verschillende scripts via een internet-browser worden aangeroepen en dus ook op verschillende platforms. Hierbij kan gebruik worden gemaakt van HTML met stylesheets, PHP en eventueel Python en XML.

Functionaliteiten

In dit deel van het projectplan worden de wensen qua functionaliteit van de klant besproken. Ze worden in twee categorieën onderverdeeld. De bestaande functionaliteiten die aangepast moeten worden of degene waarvoor nog een gebruikers interface moet worden gebouwd, om het gebruik ervan te facilitairen. Onder een script verstaan we een klein programmaatje dat een specifieke functionaliteit uitvoert.

Bestaande functionaliteiten

Bepaalde scripts bestaan al, maar zullen misschien hier en daar kleine aanpassingen nodig hebben om er een fatsoenlijke interface bij te kunnen maken. Dit is het geval bij de volgende scripts:

Bestaande functionaliteiten die aangepast moeten worden:
  • autoload: voert automatisch taken uit op een client zodra deze zich aanmeld op de server
  • create_home: voegt nieuwe gebruikers toe (team of leerling); enkel of lijst met of zonder verwijzing naar een bestaande gebruiker.
  • mv_home: verplaatst gebruikers naar een nieuwe groep; enkel of lijst
  • del_home: verwijdert gebruikers (team of leerling) inclusief de daarbij behorende omgeving; enkel of lijst
  • bpbatch(load.bpb)- applicatie installatie: tijdens het opstarten van de client computer zorgt dit script ervoor dat er een Windows besturingssysteem wordt geïnstalleerd met een aantal specifieke applicaties op de client.
  • Nwe_school: het aanpassen van de schoolnaam. Momenteel wordt bij aanpassing van de naam, elk voorkomen van die naam meteen aangepast.
  • backup fsdump: maakt dagelijks of wekelijkst een backup van de belangrijkste gegevens naar tape, disk, of internetspace. Het moet de mogelijk bieden om bij bepaalde intervallen automatisch een backup van de server te maken en die ergens anders naartoe te schrijven. De instellingen moeten aanpasbaar zijn via de webinterface.

Nieuwe functionaliteiten

De opdracht van GiPLAN houdt in; het maken van (een opzet voor) ëë interface. De interfacing zelf wordt in een ander hoofdstuk besproken. Het kan voorkomen dat er nieuwe functionaliteit moet worden toegevoegd, naarmate de ontwikkeling van de interface vordert. Het is alleen niet GiPLAN's primaire taak deze scripts te gaan schijven. Er kan gedacht worden aan:

Eventuele nieuwe functionaliteiten
  • includes.bpb: biedt informatie over welke applicaties te kiezen zijn en op welke plaats de te laden bibliotheken en/of register sleutels zich bevinden.
  • [applicatie_naam].bpb: bevat informatie over of een .imz file gebruikt moet worden om een applicatie op een client te laten werken. Het biedt informatie of er registry sleutels moeten worden gezet
  • [applicatie_naam].imz: deze bevat de gezipte bestanden die nodig zijn op een client, applicatie afhankelijke bibliotheken
  • [applicatie_naam].reg: deze bevat het register sleutels die nodig zijn om op een client een applicatie te laten werken
  • quota: biedt de mogelijkheid om gebruikersruimtes te wijzigen per groep of per gebruiker
  • sizes.bpb: levert de grootte van de image voor de cache client op, dit is belangrijk voor de installatie
  • check for wrong url: Dit biedt de mogelijkheid om een geschiedenis met betrekking tot internet gebruik van de gebruikers bij te houden. Zo kun je door middel van steekwoorden die op URLs voorkomen bepalen als een gebruiker te vaak 'black words' op internet pagina's tegen komt. Dan moet automatisch een bericht naar de systeembeheerder gestuurd worden.
  • set user environment: (hoge prioriteit) dit biedt de mogelijkheid tot het maken van een gebruikers omgeving. Hierbij moeten alle ins en outs van een gebruiker ingesteld worden (setting policy, registry settings, wat wel/niet mag). Deze instellingen zijn terug te vinden in User.dat.
  • dhcpd: dit biedt de mogelijkheid om adressen van netwerk kaarten in te voeren. Het geeft aan waar de image in de server vandaan moet worden gehaald voor de client.
  • squirm: dit moet de mogelijkheid bieden een 'black list' van URLs op te geven zodat toegang tot die URLs niet wordt verleend

Optionele delen

Om de gebruikersvriendelijkheid van het systeem te optimaliseren, kan het handig zijn dat er allerlei Windows-rechten via de, door GiPLAN te ontwikkelen, interface kunnen worden ingesteld. Dit zou betekenen dat er in de betreffende user.dat's (het Windows register) aanpassingen gemaakt moeten gaan worden. Omdat dit niet tot GiPLAN's primaire taak behoord blijft deze sectie optioneel totdat er mocht blijken dat GiPLAN tijd over heeft.

Prioriteiten

Deze volgende paragraaf geeft aan welke delen van het programma de hoogste prioriteit hebben. Hieronder volgt een opsomming van de scipts die voor de fuctionaliteit zorgen. De scripts met de hoogste prioriteit staan bovenaan, met de laagste prioriteit onderaan.

  1. create_home, move_home, del_home, diskquota
  2. BPBatch-gebeuren; dit heeft voornamelijk te maken met het maken van images, het instellen welke client welke images kan laden en welke programma's/applicaties er mee worden gekopieërd.
  3. Nwe_school
  4. Back_up, copy_disk
  5. Squirm
  6. set_user_env, check_for_wrong_url; beiden bestaan nog niet als script

3: Niet-functionele vereisten

Inleiding

In dit hoofdstuk worden de niet-functionele vereisten besproken. Deze beschrijven waar de interface aan moet voldoen met betrekking tot onder andere vormgeving, taal, aanpasbaarheid en systeemvereisten.

Systeemvereisten

De door GiPLAN te ontwikkelen interface draait op een client-server systeem. Op het server gedeelte moet het schoolLAN systeem draaien en het moet dus minimaal aan de systeemvereisten voor schoolLAN voldoen. Het gaat hier om een op Linux gebaseerde server. De server moet uitgerust zijn met een webserver die PHP, HTML4 met CSS en eventueel Python ondersteunt.

Aan een enkele server, waar schoolLAN op draait, moeten ongeveer 50 workstations aan kunnen hangen, met in totaal 250 gebruikers. In principe is er door clustering van servers een netwerk met 500 workstation en 1500 tot 2000 gebruikers mogelijk.

Wanneer men de clients ook wil gebruiken om de, door GiPLAN te ontwikkelen, interface aan te spreken, moeten de clients beschikken over een grafische Internet- browser met de mogelijkheid om plaatjes, tabellen en formulieren weer te geven.

Foutafhandeling

De reeds aanwezige scripts geven foutmeldingen wanneer er iets onverwachts of ongewenst gebeurd. Deze meldingen moeten door het systeem worden opgevangen en op een duidelijke en overzichtelijke manier worden doorgespeeld naar de gebruiker. Aan de hand van de ernst van de fout kan er gekeken worden of de systeembeheerder op de hoogte gesteld moet worden.

Beveiliging

De gebruikers van het systeem worden geidentificeerd aan de hand van hun unix login. De te ontwikkelen interface kan gebruik maken van deze unix login, d.m.v. bijvoorbeeld PHP. We mogen er vanuit gaan dat de veiligheid door het gebruik van hiervan gewaarborgd is.

Vormgevingseisen

De verschillende pagina's van de te ontwikkelen interfaces zullen dezelfde layout gebruiken om zo een consistente interface te vormen. Deze gebruikersinterface dient makkelijk in het gebruik te zijn. Dat wil zeggen dat er vanaf het scherm voor de gebruiker duidelijk is af te lezen wat zijn mogelijkheden zijn en hoe hij die kan toepassen.

Verder zal er bij het schrijven en aanpassen van de scripts rekening gehouden moeten worden met de documentatie. Alle opgedane kennis moet bruikbaar zijn voor de volgende lichting die zich hier mee bezig zal houden. Hiermee wordt bedoeld dat documentatie in de vorm van manual pagina's, zoals die in Unix bestaan (het commando man), zullen worden geschreven en beschikbaar worden gemaakt.

Taal

De voertaal van het programma is Nederlands. De voertaal van de interface is Nederlands. De documentatie en het eventuele commentaar in de code is in het Nederlands.

4: Benodigdheden van klant

In deze paragraaf wordt besproken wat van de klant wordt verwacht. Het is voor ons een leer-ervaring, maar GiPLAN verwacht wel zo veel mogelijk ondersteuning van de klant te krijgen, daar waar hij ons dat kan bieden. Hiermee bedoelen we dat hij bereid is afspraken met ons te maken om het project te bespreken maar ook de ideëen van de gebruikers doorspeelt of desnoods een afspraak met een van de gebruikers te organiseren. GiPLAN eist bij elke iteratie in ons spiraalmodel een vorm van goedkeuring of kritiek te ontvangen. Zo kunnen wij bij misverstanden op tijd ingrijpen en zodat de problemen niet te groot worden. Wat er nodig is:

  • Het huidige programma inclusief de bestaande gebruikers handleiding;
  • Eisen, voorkeuren en verwachtingen met betrekking tot de gebruikers interface;
  • Feedback na elke iteratie of gebouwde module;

5: Haalbaarheid

Met de huidige opzet van het project moet het in ieder geval mogelijk zijn om de gedeelten van de interface met de hoogste prioriteit te realiseren. Omdat we wel moeten weten hoe de huidige scripts werken, gaat er extra tijd zitten in onderzoek naar die werking. Verder zal in de loop van het project nogmaals moeten worden vastgesteld wat allemaal precies wel en niet binnen de geplande tijd haalbaar is. Alle delen met de hoogste prioriteit zullen in ieder geval geïmplementeerd worden. Voor de delen die niet volledig geïmplementeerd worden, zullen we, waar mogelijk, een opzet maken. Alle, door ons opgedane, kennis zal in ieder geval vast worden gelegd zodat anderen daarmee makkelijk uit de voeten kunnen.