Inleiding

Wie zijn wij?

Het GiPHouse is een softwarehouse binnen de Katholieke Universiteit Nijmegen. In dit softwarehouse wordt een leersituatie gecreëerd voor studenten Informatica door het Software Engineering proces, zoals bekend uit het bedrijfsleven, te doorlopen.

Voor studenten is dit vak dus een omgeving waarin eens geproefd kan worden aan de realiteit van de wereld, waarin ze al dan niet na de studie terechtkomen. Doelstelling is praktijkcases na te bootsen in de beschermende omgeving van de School voor Informatica. Alle rollen die binnen het bedrijfsleven te vinden zijn worden in een viertal vakken zo goed mogelijk nagebootst.

In GiP1 en GiP2 wordt het traject van een projectteam nagebootst. In GiP3 en GiP4 doorloop je het traject van de managers. Omdat wij op dit moment in GiP2 zitten, vormen wij het projectteam "GiPLAN". Deze naam is zo gekozen, vanwege onze klant (zie "wie is onze klant?").
Ons team bestaat uit de volgende personen: Pim Krebbers, Mirko van Ede, Renske Weeda en Joost Koppers. Onze manager is Dave Boschma.

Wie is onze klant?

De klant is Stichting schoolLAN uit Arnhem. Ons contactpersoon is dhr. Ruud Suk. schoolLAN is een landelijke organisatie voor coördinatie van schoolLAN-techniek en schoolLAN-organisaties. Het is een blauwdruk en een soort "kookboek" (hoe en wat) van een lowbudget computernetwerksysteem voor (basis)scholen, gericht op en opgezet vanuit de praktijksituatie bij (basis)scholen met gebruikmaking van de op een school aanwezige hardware, software en besturingssystemen.

ShoolLAN is nadrukkelijk als Open Source opgezet, omdat technologie gezien wordt als een middel om publieke belangen te behartigen en niet als middel om individuele winsten te behalen. Via samenwerkingsvormen (regionale schoolLAN stichtingen) tussen (basis)scholen (de praktijk), middelbare en hogere beroepsopleidingen informatica en lerarenopleiding, wordt schoolLAN verder ontwikkeld (gericht op distribueerbaarheid, onderwijs en didactiek ontwikkeling) en vormgegeven zodat continuïteit en ontwikkeling gewaarborgd wordt.

Project voorstel

Het doel van dit project is: het ontwikkelen van een user-interface te versnellen, zodat de verschillende scripts, die schoolLAN aanbiedt, makkelijkker te gebruiken zijn. Dit heeft als doel de (technische) gebruiker, systeembeheerder en docenten van de basisscholen, het makkelijker te maken. Op dit moment moeten er nog moeilijke scripts op de command-line worden aangeroepen. Aangezien er op basisscholen vaak minder kennis is van netwerken en software aanwezig is, is er de vraag naar een cognitief- en ergonomisch veranwoordelijke interface.

Dit houdt dus in: het bouwen van cognitief-ergonomisch interface. Dit door middel van het opzetten van een basis waaraan makkelijk door derden verder gewerkt kan worden. En waar makkelijk door minder technische mensen mee gewerkt kan worden.

Aanpak

Opzetten Project

Na een algemeen inleidend verhaal van ons management zijn we naar onze klant gegaan om van hemzelf een schets van de opdracht te krijgen. Hierdoor hebben wij een beter idee van het probleem gekregen en ook wat er van ons verwacht werd. Vervolgens hebben wij een projectplan opgesteld [zie: Projectplan] waarin afgebakend beschreven staat wat de opdracht luidt, hoe wij van plan zijn dat aan te pakken en wat er allemaal precies van ons verwacht werd. We hebben in kaart gebracht welke onderdelen er gemaakt moesten worden, wat hun afhankelijkheden zijn en in welke volgorde deze onderdelen op een logisch manier aanpak moeten worden. [zie: Prioriteiten-boom]. Omdat het projectplan een prima beschrijving is van de afspraken tussen het team en de klant kon het prima fungeren als een contract. Na terugkoppeling van de klant hebben we de prioriteiten-boom en het projectplan verfijnd. Voor de volledigheid hebben we deze ook, na akkoord, door onze klant laten ondertekenen.

Oriëntatie Systeem

Om te beginnen hebben we ons georiënteerd op het huidige schoolLAN systeem. Er bleken in de huidige scripts een aantal problemen vreemd te zijn aangepakt of opgelost, hetgeen eventueel voor ons problemen zou kunnen opleveren. Aangezien wij naast het bouwen van een user-interface ook nog een adviserende rol hadden, hebben we de door ons geconstateerde gebreken en mankementen vastgesteld en gedocumenteerd [zie: Error-document]. Deze hebben we aan onze klant overhandigd zodat hij kon beslissen wat daarmee zou moeten gebeuren. Het aanpakken van deze problemen valt buiten het scope van onze project. Verder hebben we als advies ook nog een document opgesteld met daarin onze aanbevelingen. Hierin wordt onder andere uitgelegd hoe het schoolLAN-systeem beveiligd kan worden en tevens worden verdere verbeteringen aangedragen [zie: Aanbevelingen].

Cognitieve Aspecten

Bij het bouwen van een interface moet uiteraard rekening gehouden worden met de gebruikers. Niet alleen moet de software goed functioneren, maar de toekomstige gebruikers moeten er ook met gemak mee om kunnen gaan. Daarom hebben we een cognitief onderzoek gedaan [zie: Cognitief Onderzoek]. Hierin staan aanwijzingen over wat wel en absoluut niet in een interface moet voorkomen.

Aan de hand van dit cognitief onderzoek hebben we een eerste opzet van de interface gemaakt. Omdat de interface toch wel standaarden moet hebben en consequent moet zijn hebben wij besloten om gebruik te maken van stylesheets en templates. Zo zullen alle documenten hetzelfde uiterlijk hebben, evenals alle pagina's van de interface. Dit ziet er niet alleen mooi uit, maar oogt ook rustig en door de consistentie is het gebruik ervan een stuk soepeler. Verder is het door het gebruik van stylesheets mogelijk voor een (basis)school zijn interface aan te passen aan zijn eigen wensen. Zo kan bijvoorbeeld eenvoudig de achtergrondkleur van de interface aangepast worden (het hoeft maar op een plaats te gebeuren) zodat een (basis)school hun eigen kleur als achtergrond kan kiezen. Het gebruik van de stylesheet en de templates is uitgebreid gedocumenteerd. [zie: Systeem Beschrijving en Templates].

De klant heeft ons gevraagd om het door ons te onwikkelen systeem zo eenvoudig te maken, zodat een gebruikers handleiding overbodig zou moeten zijn. Uiteraard moet de gebruiker wel aanwijzingen krijgen. Dit hebben wij gedaan door voldoende (maar ook niet teveel) instructies op het scherm te plaatsen.

We proberen de gebruiker zo veel mogelijk te ondersteunen bij het invoeren van data. Zo hebben we drie invoer mogelijkheden om de gebruiker in verschillende gevallen te ondersteunen:

  • Gegevens van een enkele leerling toevoegen: om de gegevens van een gebruiker aan te passen maken we gebruik van formulieren waarin de huidige gegevens van de gebruiker ingevoerd kunnen worden. De gebruiker heeft ook de mogelijkheid om een gebruiker te zoeken uit een lijst (gesorteerd op groep om makkelijk in te kunnen zoeken) of gewoon rechtstreeks in te voeren. Vervolgens wordt gecontroleerd of de gebruiker, waar naar verwezen wordt, wel bestaat of niet (waar dit van toepassing is). Alleen een bestaande gebruiker kan verwijderd worden.
  • Meerder leerling-gegevens tegelijk toevoegen: hiervoor hebben we de mogelijkheid gecreeërt om door middel van een batch bestand, dus een tekst bestandje met alle toe te voegen gegevens, in een keer meerdere gebruikers toe te voegen. Eventuele foutmeldingen worden achteraf in een keer voor het hele bestand getoond. Vervolgens wordt er van de gebruiker geëist dat die fouten eerst hersteld worden voor dat het definitief invoeren van de gegevens kan plaatsvinden.
  • Leerlingen promoveren: Op het eind van het schooljaar worden bijna alle leerlingen van een klas worden gepromoveerd naar een klas hoger, en zo moeten ze in de bestaande groepen in onze systeem ook 'promoveren'. We begeleiden de gebruiker stap voor stap door het proces, door middel van tekstuele hulp op het scherm. We gaan ervan uit dat de meeste kinderen in een klas promoveren, en er dus maar een klein gedeelte blijft zitten. We hebben er dus voor gekozen alle leerlingen in een klas, per definitie, te selecteren. De gebruiker van ons systeem moet dus de 'zittenblijvers' deselecteren en niet de te promoveren leerlingen selecteren. De leelingen die promoveren uit groep 8 worden verwijderd uit het schoolLAN-systeem.
Verder is er ook nagedacht over de invoer vormen:
  • Formulieren: de gebruiker voert gegevens in een tekstbox in. Dit is overzichtelijk maar ook veiliger bij controles op bijvoorbeeld invoerlengte en invoergeldigheid.
  • Zoeken: bij het selecteren van bestaande gebruikers voor bijvoorbeeld verwijderen of verplaatsen, wordt altijd de mogelijkheid geboden om een gebruiker uit een lijst te selecteren. Door te zoeken kan een gebruiker hier geen ongeldige informatie invoeren, de door ons gegenereerde lijst bestaat immers alleen uit geldige opties. Verder beperkt dit tikfouten en hoeft de gebruiker de gegevens niet zelf tijdelijk te onthouden, hetgeen ook vaak tot fouten en irritaties lijdt.
  • drop down box: als een gebruiker moet kiezen uit vaste opties wordt voor het gemak een drop down box gebruikt. Zo is het voor de gebruiker meteen duidelijk welke invoer mogelijk is en kunnen er geen ongeldige keuzes gemaakt worden.
Herstellen na een fout detectie:

Als er in een formulier een foutieve invoer wordt ontdekt dan wordt het in gevulde formulier in zijn geheel weergegeven, met uitzondering van de veld(en) waar een incorrecte invoer stond, deze zullen leeg geretourneerd worden. Dit voorkomt dat goed ingevulde velden eventueel opnieuw ingevuld moeten worden en daardoor de kans verhogen op een tikfout. Verder is het voor de gebruiker overzichtelijk om te zien welke gegevens foutief ingevuld werden.

Voordat een opdracht ook daadwerkelijk wordt uitgevoerd wordt de gebruiker nog eenmaal gevraagd om een bevestiging. Op het moment dat er om een bevestiging wordt gevraagd worden de te wijzigen gegevens weergegeven en de mogelijkheid geboden om of terug te gaan, of te accepteren en dus door te gaan. Als de gebruiker op dit moment aangeeft dat een of meer gegevens niet kloppen wordt hij teruggestuurd naar het formulier zoals die door de gebruiker was ingevuld. Zo hoeft de gebruiker alleen het veld aan te passen dat foutief was en niet het gehele formulier opnieuw invullen. Dit voorkomt ook een hoop tikfouten en frustraties bij de gebruiker.

Omdat het installeren wel wat extra inspanning vergt hebben we hiervoor een korte uitleg opgesteld [zie Installatie handleiding].

Prototype

We hebben de eerste opzet van de interface naar de klant gebracht ter goedkeuring. Op dit moment was er nog maar weinig functioneel. Na goedkeuring van de klant zijn we op dezelfde stijl incrementeel verder gegaan en hebben we de functionaliteit ingevuld. Ook hebben we de interface verder uitgebreid en de prioriteiten-lijst zoals in de prioriteiten-boom beschreven staat afgewerkt. Tussentijds zijn we nog meerdere keren naar de klant terug gegaan om onze vorderingen te tonen. Hierbij vroeg de klant zo nu en dan nar een uitbreiding van de functionaliteit, die wij daarna, na overleg, al dan niet hebben ingebouwd.

Testen

Testen is een van de belangrijkste onderdelen van het op te leveren systeem. We hebben een document opgesteld waarin duidelijk staat wat onze eisen zijn en onder welke voorwaarden we achten dat het systeem correct moet functioneren. Ook houden we rekening met het feit dat het systeem moet functioneren zoals uit het Cognitief Onderzoek is gebleken. Naast deze eisen hebben we ook een systematisch testplan opgezet om te kunnen controleren of het systeem in alle randgevallen qua invoer het correcte resultaat oplevert. Dit staat gedocumenteerd in het testplan [zie: Testplan].

Naast het door onszelf laten testen van het systeem hebben we ook meerdere buitenstaanders erachter gezet. De informatie op het scherm moet genoeg zijn om er mee om te kunnen gaan. Hiervoor hebben we drie soorten mensen gepakt:

  • een op academisch niveau opgeleide ergonoom,
  • een echte leek met weinig computer ervaring die we van de straat hebben geplukt en
  • onze daadwerkelijke uitgebruikers.
De resultaten van deze test staan gedocumenteerd in het testplan, evenals een verantwoording en bedachte oplossingen voor de knelpunten.

Conclusie

We zijn erg tevereden met het door ons ontwikkelde systeem. Ook de reacties van onze klant en de daadwerkelijke gebruikers waren erg positief. We hebben met plezier aan dit project gewerkt en we zijn blij dat we ons steentje hebben kunnen bedragen aan zo'n goede stichting als schoolLAN. We hopen ook dat onze adviezen die beschreven staan in het error-document en het document met onze aanbevelingen schoolLAN verder kunnen helpen hun werk voor te zetten.