Project Plan1: InleidingDit 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 klantDe 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 huidige situatieHet 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 opdrachtDoel 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. AanpakWij 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:
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. OpbouwDe rest van dit document is als volgt opgebouwd:
2: Functionele vereistenInleidingIn dit deel van het projectplan wordt beschreven wat de functionaliteiten van het systeem zijn. InterfaceDe 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. FunctionaliteitenIn 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 functionaliteitenBepaalde 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:
Nieuwe functionaliteitenDe 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
Optionele delenOm 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. PrioriteitenDeze 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.
3: Niet-functionele vereistenInleidingIn 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. SysteemvereistenDe 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. FoutafhandelingDe 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. BeveiligingDe 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. VormgevingseisenDe 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. TaalDe 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 klantIn 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:
5: HaalbaarheidMet 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. |