STORING EN MONITORING

STORING EN MONITORING BSC-PROJECT

IN3405

STORING EN MONITORING BSC-PROJECT

IN3405

Kilian Croese - 1262920 Michel Fiege - 1262955 Bas Schoenmakers - 1265199 Bas Wenneker - 1213865

Tenuki BV Technische Universiteit Delft, Faculteit Elektrotechniek, Wiskunde en Informatica 2 juli, 2008

Examen commissie: David Koh Tenuki Dr. P.G. Kluit Ir. B.R. Sodoyer Technische Universiteit Delft

ii

VOORWOORD Tenuki, gelegen in Delfgauw, is een klein softwarebedrijf voornamelijk gericht op het maken en onderhouden van verkeersinformatie gerelateerde software en diensten. Verkeersinformatie is op verschillende manier te verkrijgen, zo worden er meldingen gedaan door de ANWB, Rijkspolitie, of Spitsgidsen.Een andere bron van informatie zijn detectielussen die op de Nederlandse A-wegen in het wegdek verzonken liggen. Tenuki levert systemen waarbij deze gegevens, indien nodig, ingevoerd, verwerkt en geïnterpreteerd kunnen worden. Een andere dienst die ze leveren, die zeer relevant is voor onze opdracht, is het onderhouden van servers van het Verkeerscentrum Nederland (VCNL). Het komt enkele keren per dag voor dat er storingen optreden en deze moeten dan uiteraard zo snel mogelijk worden opgelost. Deze storingen moeten allemaal gerapporteerd worden, zodat later een overzicht beschikbaar is van de behandelde storingen. Om te voorkomen dat er situaties ontstaan die voor storingen kunnen zorgen, worden de servers enkele keren op een dag gemonitord. Onze opdracht is het maken van een programma dat de gebruiker ondersteunt bij deze processen. Het VCNL is één van de grootste klanten van Tenuki. Het VCNL is onderdeel van Rijkswaterstaat en is de instantie die de beschikbare verkeersinformatie vrijgeeft aan marktpartijen. Enkele andere klanten zijn de ANWB en TomTom. Het bedrijf heeft 11 werknemers die zowel parttime als fulltime bij Tenuki werken. Dit team bestaat uit Delphi programmeurs, webontwikkelaars (PHP &DotNetNuke), een grafisch ontwerper en ondersteunend personeel. Met dit team worden de verschillende applicaties ontwikkeld. Dit verslag is geschreven in het kader van de stage die in het laatste kwartaal van de Bachelorfase moet worden uitgevoerd en is bedoeld om de verschillende begeleiders inzicht te geven in ons project. Tijdens de stage hebben we drie applicaties ontwikkeld die de medewerkers binnen Tenuki zullen ondersteunen tijdens enerzijds het monitoren van servers en anderzijds het registreren van storingen. Wij willen via deze weg David en Mariska in het bijzonder, maar ook de andere Tenukianen, bedanken voor de leuke en leerzame periode. Daarnaast bedanken we Dr. Kluit voor de begeleiding vanuit de Technische Universiteit Delft.

Delfgauw, 2 juli 2008 Kilian Croese Michel Fiege Bas Schoenmakers Bas Wenneker

iii

SAMENVATTING Voor het eerst deden we een projectopdracht bij een bedrijf. Fijn was, dat de stageperiode begon met een onderzoeksverslag in het derde kwartaal. Op deze manier konden we wegwijs worden bij het bedrijf en wisten we welke richting we op moesten gaan. In deze periode zijn we een aantal maal bij Tenuki geweest. We kregen te horen dat we gingen werken volgens het eXtreme Programming paradigma en dat we de opdracht in Delphi moesten gaan programmeren. Twee totaal nieuwe elementen voor ons en dus twee uitdagingen om aan te gaan. De opdracht bestond uit twee verschillende onderdelen: een monitoringsysteem en een storingsregistratiesysteem. Het monitoringsysteem moest de gebruiker ondersteunen in het monitoren van verschillende systemen van Tenuki. Deze systemen worden gebruikt door het VCNL (Verkeerscentrum Nederland). Het onderhoudscontract dat Tenuki heeft met het VCNL verplicht hen om de systemen te monitoren. Dit monitoren is preventief werk, om eventuele storingen voor te kunnen zijn. Momenteel gebeurt het monitoren met veel handwerk, dit moet geautomatiseerd worden. Tevens omvatte onze opdracht een storingsregistratiesysteem. Mochten er storingen zijn, dan moeten deze op een goede manier in een systeem gezet kunnen worden. Tevens moest het mogelijk worden om te zoeken in eerdere storingen, om zo sneller tot een oplossing te komen. Beide systemen moesten tevens rapportages kunnen genereren. In de eerste twee/drie weken van onze stageperiode zijn we bezig gegaan met het begrijpen van de Tenuki aanpak in combinatie met XP. Ook leerden we onze nieuwe ‘collega’s’ kennen en kregen we onze werkplek toegewezen. We kregen allemaal iemand van Tenuki aangewezen die ons de komende periode ging begeleiden. Het leren van de Tenuki aanpak en het gebruiken van eXtreme Programming heeft even geduurd. We moesten vaak opnieuw onze zaken formuleren en op de goede manier leren denken. Dit heeft er echter wel voor gezorgd dat we in de rest van onze stageperiode geen problemen meer hebben gehad met begrijpen van deze methodieken. We hebben onze eigen inbreng gehad in het ontwerpen van de software systemen. We hebben hier veel meegekregen van de kennis die bij Tenuki aanwezig is. Zo is er weloverwogen gekozen om gebruik te maken van een TCP verbinding waar XML over verzonden ging worden. Het uiteindelijke doel was om binnen de toegestane tijd, met behulp van de Tenuki werkwijze de systemen te ontwikkelen. Tijdens het werken bij Tenuki werd ons gevraagd om regelmatig presentaties te geven en te werken zoals de werknemers dit bij Tenuki doen. De eXtreme Programming methode liet ons werken in verschillende iteraties, die allemaal uit een analyse-, implementatie- en evaluatiefase bestonden. De korte iteraties lieten ons vroeg programmeren en hielpen ons sneller onze doelen te verwezenlijken. We hebben onze doelen weten te halen en hebben veel geleerd van onze stage. Met name eXtreme Programming en de Tenuki aanpak zijn punten geweest die we zeker zullen gebruiken in onze verdere werkzaamheden. Onze systemen zijn momenteel in gebruik en gaan hopelijk de komende jaren gebruikt worden.

iv

INHOUDSOPGAVE Voorwoord .............................................................................................................................................................. iii Samenvatting .......................................................................................................................................................... iv 1.

Inleiding .......................................................................................................................................................... 1

2.

Werkwijze ....................................................................................................................................................... 2 2.1 2.2 2.3 2.4

3.

Planning .......................................................................................................................................................... 7 3.1 3.2

4.

Iteratie 1: Rompsysteem ..................................................................................................................... 34 Iteratie 2: Beta versie .......................................................................................................................... 38 Iteratie 3: Release kandidaat ............................................................................................................... 44

Behaalde doelstelling ................................................................................................................................... 47 7.1 7.2

8.

Client/Server-side ................................................................................................................................ 22 Communicatie...................................................................................................................................... 25 Databaseontwerp ................................................................................................................................ 28 Rapportage .......................................................................................................................................... 32 Het observer design pattern ................................................................................................................ 33

Realisatieproces ........................................................................................................................................... 34 6.1 6.2 6.3

7.

Context ................................................................................................................................................ 10 Huidige situatie .................................................................................................................................... 11 Use cases ............................................................................................................................................. 14 Gebruikerssessies ................................................................................................................................ 16 Evaluatie controles .............................................................................................................................. 17 Algemeen ontwerp .............................................................................................................................. 20

Architectuur ................................................................................................................................................. 22 5.1 5.2 5.3 5.4 5.5

6.

Statische metaplanning ......................................................................................................................... 7 Dynamische iteratieplanning ................................................................................................................. 7

Wat moeten we doen ................................................................................................................................... 10 4.1 4.2 4.3 4.4 4.5 4.6

5.

Extreme programming ........................................................................................................................... 2 Tenuki aanpak........................................................................................................................................ 4 Projectbeheersysteem ........................................................................................................................... 5 Versiebeheer ......................................................................................................................................... 6

Monitoring ........................................................................................................................................... 47 Storingsregistratie ............................................................................................................................... 47

Aanbevelingen en gebreken ......................................................................................................................... 49 8.1 8.2

Aanbevelingen ..................................................................................................................................... 49 Gebreken ............................................................................................................................................. 52

v

9.

Evaluaties ..................................................................................................................................................... 53 9.1 9.2 9.3 9.4 9.5 9.6

Project evaluatie .................................................................................................................................. 53 Groepsevaluatie................................................................................................................................... 53 Kilian Croese ........................................................................................................................................ 54 Michel Fiege......................................................................................................................................... 54 Bas Schoenmakers ............................................................................................................................... 55 Bas Wenneker ...................................................................................................................................... 55

Referenties ............................................................................................................................................................ 56 Bijlage 1: Ontwerp Gui .......................................................................................................................................... 59 Monitoringsysteem........................................................................................................................................... 59 Storingregistratiesysteem ................................................................................................................................. 67 Bijlage 2: GUI resultaten ....................................................................................................................................... 71 Bijlage 3: Onderzoeksverslag ................................................................................................................................ 77 Opdrachtomschrijving ...................................................................................................................................... 77 Extreme Programming ...................................................................................................................................... 79 Plan van aanpak ................................................................................................................................................ 81 De verschillen tussen Java, PHP en Delphi........................................................................................................ 83

vi

1.

INLEIDING

Eén van de belangrijkste, stabiele stroom van inkomsten voor Tenuki is het 24-uurs beheer- en onderhoudscontract met de belangrijkste klant Rijkswaterstaat. De draaiende systemen voor de file-informatie dienen dag en nacht bereikbaar te zijn. Naast het feit dat Tenuki ieder moment van de dag gebeld kan worden voor optredende storingen, moet Tenuki twee keer per dag verschillende systemen monitoren om de service te garanderen. Het monitoren en de verslaglegging gebeurt op het moment met de hand, en is erg tijdrovend. Daarnaast dient eens per maand een aparte monitoringrapportage opgesteld te worden voor de klant. Ook de registratie van storingen en het vastleggen van de verrichte acties is handwerk. Deze laatste rapportages worden in platte tekst opgesteld en ook eens per maand apart gebundeld voor de klant. De uitdaging is om alle onderdelen, van monitorings- tot storingsrapportages, te automatiseren, waarbij het systeem de werknemers ondersteunt in hun werkzaamheden. Uiteindelijk zijn hier drie programma’s uit voort gekomen, te weten een programma om de monitoringen uit te voeren, een programma om de storingen te registreren, en een programma’s om voor de monitoringen een rapportage te genereren.

1

2.

WERKWIJZE

In dit hoofdstuk lichten we de werkwijze toe die we gehanteerd hebben tijdens het project. Tijdens het bachelorproject hebben we gewerkt volgens de eXtreme Programming (XP) methode. In de eerste paragraaf zullen we uitleggen wat dit precies inhoud en hoe we het toegepast hebben binnen het project. Enkele onderwerpen die hierbij aan bod zullen komen zijn: Test-Driven Development, Refactoring, het krijgen van feedback en het zo simpel mogelijk houden van het ontwerp. We gaan in op de manier waarop de XP methode toegepast wordt bij Tenuki. Ook behandelen we het verschil tussen XP en het watervalmodel, een model waar we mee hebben leren werken op de TU. In de volgende paragraaf zullen we de Tenuki werkwijze behandelen. Deze werkwijze wordt bij ieder project toegepast en is één van de kernzaken die nieuwelingenzichzelf bij zullen moeten brengen binnen het bedrijf. Bij deze aanpak staat het expliciet maken van het doel centraal. Er wordt gekeken naar wat er gemaakt moet worden en hoe dat gebruikers kan ondersteunen. Wanneer dit helder is kan er gekeken worden naar de technische invulling van de oplossing. In de laatste twee paragrafen zullen we ingaan op enkele software hulpmiddelen die we tijdens het project hebben gebruikt, te weten Trac en Subversion. Met behulp van beide toepassingen, hebben we het werken binnen het project vereenvoudigd en overzichtelijker gemaakt.

2.1

EXTREME PROGRAMMING

In ons vooronderzoek hebben we verschillende aspecten van XP onderzocht. In deze paragraaf wordt verteld in hoeverre we deze aspecten terug hebben laten komen in ons project en hoe we eXtreme programming hebben leren kennen tijdens onze stage. Laten we allereerst vaststellen dat XP een methodiek is die gebruik maakt van andere methodieken en deze tot in het extreme doorvoert. Zo hebben wij, net zoals bij Tenuki, onder andere gebruik gemaakt van Test Driven Development en refactoring. Bovendien zijn feedback en de eenvoud van ontwerp belangrijke factoren gedurende het ontwikkelproces. Een ander element uit XP, Pair Programming, hebben we weinig toegepast, voornamelijk omdat dit binnen Tenuki niet veel gehanteerd wordt. Vanwege het feit dat we dit tijdens onze studie wel als fijn hebben ervaren, is het wel af en toe toegepast tijdens de stage. Ten slotte behandelen we in deze paragraaf het verschil tussen XP en het watervalmodel, waar we mee hebben leren werken tijdens het software technologie project.

TEST DRIVEN DEVELOPMENT Het werken aan de hand van unit tests brengt, zo hebben wij ervaren, grote voordelen met zich mee. Er kan een hoop tijd mee gewonnen worden. Zo wordt bijvoorbeeld het opsporen van fouten in het programma een stuk gemakkelijker met goed geschreven unit tests. Het werkprincipe is omgekeerd aan wat we gewend waren. In plaats van het schrijven van code, die vervolgens getest wordt, wordt er in omgekeerde volgorde gewerkt. Dus: eerst worden de unit tests geschreven en daarna wordt pas de code geïmplementeerd zodat de unit tests slagen. Dit heeft tot resultaat dat tests zorgvuldiger geschreven worden en hetmaakt het werken ook een stuk leuker, omdat het testen erg gemakkelijk gaat. Een ander voordeel is dat aan de nog falende unit tests precies de voortgang is af te lezen.

2

REFACTORING Refactoring is het herschrijven en herstructureren van code.Refactoring gaat uitstekend samen met unit tests. Doordat er achter elke unit eentestsuite hangt, is het erg gemakkelijk te controleren of de code na refactoring nog steeds dezelfde output geeft. Met een goede testsuite op de achtergrond kan het herschrijven van code heel snel gaan en bovendien is er de zekerheid dat, als de test slaagt, het programma niets aan functionaliteit heeft ingeleverd. We hebben tijdens het project veel gebruik gemaakt van de test suites. Het wijzigen van de code kon op deze manier met een stuk minder risico gedaan worden.

FEEDBACK Feedback heeft alles te maken met de terugkoppeling van jouw verhaal naar de opdrachtgever, maar ook naar de eindgebruikers. Door de vele gesprekken, één op één, maar ook presentaties voor bijvoorbeeld een gedeelte van de eindgebruikers, hebben we ons in elke iteratie van het project steeds opnieuw kunnen focussen op de wensen van de gebruikers. Zo is het in het begin, wanneer nog lang niet alles van de opdracht helder is, heel belangrijk om duidelijk te krijgen wat de gebruiker precies wil kunnen met het programma. Wellicht zijn er meerdere soorten gebruikers, met allemaal specifieke wensen. Door te luisteren en terug te koppelen hebben we geprobeerd zo goed mogelijk met zowel de opdrachtgever als de gebruikers op één lijn te komen en de juiste verwachtingen te scheppen. Door te doen aan verwachtingsmanagement, weet de gebruiker heel goed waar hij/zij aan toe is. Door puur vanuit het doel van het systeem te kijken, kunnen betere oplossingen ontstaan. Een gebruiker heeft namelijk bepaalde wensen, zo lang deze zijn doel maar vervullen. Meestal heeft de gebruiker ook een oplossing voor deze wensen voor ogen. Door te doen aan verwachtingsmanagement zou je zelf, als programmeur, een betere oplossing kunnen bedenken om het doel te ondersteunen. De gebruiker zal dit accepteren omdat er vanuit zijn benadering gedacht is, en het de functionaliteit ten goede komt. Dit kan vaak voor beide partijen goed uitkomen.

EENVOUD VAN ONTWERP Voor ons was dit beginsel waarschijnlijk de moeilijkste om aan te wennen. Het steeds weer exactdat programmeren wat van jeverwacht wordt en niets meer. Hierdoor wordt er nooit teveel werk gedaan. Bovendien kan de programmeur zich zorgeloos focussen op de simpelste implementatie van het ontwerp, omdat er geen rekening gehouden hoeft te worden met eventuele toekomstige uitbreidingen of herbruikbaarheid. Uiteraard moeten deze wel in acht worden genomen bij het ontwerpen van het rompsysteem, de eerste versie van het systeem. Door al in een vroeg stadium alle functionaliteiten op een rij te hebben en deze in de breedte mee te nemen, wordt al snel duidelijk wat het systeem kan. Door deze vervolgens op te delen in prioriteiten en de belangrijkste zaken als eerste aan te pakken, ontstaat altijd een goed systeem. Mocht er eerder een oplevering nodig zijn, dan van te voren gepland, is dit mogelijk. De belangrijkste functionaliteiten zitten erin en er is altijd een draaiend en goed werkend programma.

3

VERSCHIL MET WATERVALMODEL Tijdens het ST4 project hebben we leren werken met het watervalmodel. Dit model behandelt verschillende fasen van de software ontwikkeling in een vloeiende lijn van boven naar beneden. Elke fase wordt eenmaal uitgevoerd en bereidt een volgende fase voor. De eerste fasen, bestaande uit: analyse, basisontwerp en technisch ontwerp bevatten veel documentatie. De requirements analyse is een zeer belangrijke fase bij het watervalmodel. Er zal van te voren exactduidelijk moeten zijn wat er in elke fase moet gebeuren. Er zijn veel facetten binnen eXtreme Programming waar we erg aan moesten wennen. De fasen werden iteraties, waarbinnen elke keer de analyse en ontwerp-, implementatie- en evaluatiefase terugkwam. Aan het begin van het project hoeft niet exact bepaald te worden wat er in elke iteratie gedaan moet worden. De korte iteraties zorgden ervoor dat we zeer snel konden beginnen met programmeren. Dit bracht echter ook met zich mee dat we vaak terugkoppeling nodig hadden van de gebruiker. De gebruikers zijn de werknemers van Tenuki zelf. Zij waren constant in de buurt, hetgeen de XP werkwijze vergemakkelijkte. De korte iteraties zorgden ervoor dat de gebruiker snel zaken kon zien van het programma en er alvast aan kon wennen. De ervaring heeft Tenuki geleerd dat gebruikers pas echt weten wat ze willen, als ze iets hebben om naar te kijken en te kunnen gebruiken. Het is fijn om vroeg te weten waar gebruikers heen willen, zonder dat er teveel programmeerwerk aangepast zal moeten worden. We waren gewend om veel te documenteren en veel ontwerpzaken uit te tekenen met behulp van UML. Tijdens dit project moesten we documenteren wat wij achtten dat nodig was. Het is belangrijk om zaken als een databasemodel en een deploymentdiagram te hebben, maar klassendiagrammen zijn alleen echt nodig als er een overzicht nodig is om goede code te schrijven. We hebben dus een stuk minder documentatie geschreven in de analysefase en konden een stuk sneller beginnen met programmeren. In elke iteratie werd er gekeken naar het beoogde resultaat en het behaalde resultaat. Waarom zijn zaken niet gehaald die van te voren wel gepland waren? Wat vond de gebruiker van de dingen die hij/zij gezien heeft? Zaken als een planning maken, de korte fasen en het van te voren niet weten waar je eindigt zijn een groot verschil met het watervalmodel.

2.2

TENUKI AANPAK

In deze paragraaf zullen we dieper ingaan op wat de Tenuki aanpak precies inhoudt. In de loop der jaren is er binnen Tenuki een eigen softwareontwikkelingsmethodiek ontwikkeld. Enkele elementen uit XP komen hier heel duidelijk in terug. Het is een samenhang van verschillende modellen, maar die allemaal nodig zijn om een goed stuk software te ontwikkelen. Een project begint met het duidelijk krijgen van het doel, ook wel het ‘wat’ genoemd. Samen met het ‘hoe’ is dit een kreet die we veelvuldig tijdens de stage hebben gehoord, maar hierover later meer. Bij het onderzoeken van het ‘wat’ wordt er gekeken waarom de applicatie gemaakt moet worden en waarin hij de gebruikers kan gaan ondersteunen. In ons project zijn we de eerste twee weken bezig geweest met het onderzoeken wat het probleem precies was en hoe we daarbij de gebruikers het beste kunnen helpen. Tijdens deze fase hebben we al veel gepraat met de toekomstige gebruikers over hun verwachtingen, zodat we duidelijk kregen welke richting we op moeten.

4

Wanneer het ‘wat’ duidelijk is, kan er begonnen worden met het ‘hoe’. In deze stap wordt gekeken op welke manier het ‘wat’ bereikt gaat worden. Er zijn vaak verschillende manieren om een doel te bereiken. Er zullen goede overwegingen gemaakt moeten worden. Belangrijk is dat het ‘hoe’ bepaald wordt, voordat er wordt begonnen met programmeren. Op deze manier is iedereen het van te voren eens over de wijze en wordt er geen nutteloos werk verricht. Tijdens het project probeerden wij vaak ‘wat’ vragen te beantwoorden met ‘hoe’ antwoorden. In het begin was het lastig om het verschil te zien. Naarmate we dit meer zagen, bleek ook het nut hiervan een stuk duidelijker. Klanten hebben niks aan ‘hoe’ oplossingen, ze zijn geen technische mensen. Blijven denken vanuit het gedachtegoed van de klant is heel belangrijk. “Ik ga naar de Albert Heijn, is een antwoord uit de ‘wat’-fase. Maar ‘hoe’ je daar komt, dat kan op een heleboel manieren.” Belangrijke derde stap binnen de Tenuki aanpak is het tijdig aangeven van problemen. Alleen op deze manier kunnen dingen snel opgelost worden en weet iedereen waar hij/zij aan toe is. Ook wij zaten regelmatig met vragen waarvan we het antwoord niet zeker wisten, of waarvan we niet helemaal wisten hoe ze bedoeld waren. Zeer belangrijk is het dan om dit van te voren aan te geven zodat het opgelost kan worden. Ook het niet zonder meer aannemen van zaken van de gebruiker is belangrijk. Er blijft een verschil tussen de gebruiker en de opdrachtgever. Met beide moet overlegd worden en met beide moeten zaken doorgenomen worden. Maar uiteindelijk beslist de opdrachtgever. Het is zeer zeker belangrijk om dit niet uit het oog te verliezen. De laatste stap is een stap waar wij iets minder mee te maken hebben gehad. Als iets af is gerond, moet dit gemeld worden. Belangrijk hierbij is dat ook aangegevenwordt waar het te vinden is. Binnen Tenuki kunnen verschillende mensen aan een zelfde project werken. Mocht iemand op vakantie gaan of er even niet zijn, dan moeten mensen niet heel lang bezig zijn om dat ene stukje code te vinden.

2.3

PROJECTBEHEERSYSTEEM

Gedurende ons project hebben we de communicatie onder andere laten verlopen via een webbased projectbeheersysteem. Dit systeem, genaamd Trac(zie figuur 1), hebben we gekozen, omdat deze mooi kan samenwerken met een versiebeheer-tool zoals Subversion. Het basisprincipe van Trac is gebaseerd op wiki-achtige pagina’s, uitgebreid met een module om de timeline van een project bij te houden. Zo kan er worden afgestreept wat gehaald is in een bepaalde periode, de zogenaamde milestones. Wij hebben voornamelijk gebruik gemaakt van de wiki functionaliteit. Zo hebben we gedurende ons project steeds stukjes voor het verslag erop gezet, genotuleerde gesprekken uitgewerkt en planningen gemaakt en bijgehouden. De timeline-tool hebben we voornamelijk gebruikt voor de wat algemenere planning.

5

Figuur 1: Screenshot van ons projectbeheersysteem

Op deze manier was het eenvoudig voor mensen van buitenaf om te volgen waar we mee bezig waren, maar hadden we ook zelf een goed overzicht van het gedane werk. Doordat Trac de mogelijkheid biedt om door de SVN repository (zie volgende paragraaf) te bladeren, werd het eenvoudig om die data gestructureerd te bekijken en te gebruiken binnen onze verslaglegging. De timeline geeft een goed overzicht van het gedane werk per dag. Zo konden we steeds terugkijken wat we gedaan hadden en waarom we dit gedaan hadden. We hebben de milestones weinig gebruikt. Aangezien we gebruik maakten van een dynamische faseplanning (zie hoofdstuk 3), wisselde de planning regelmatig en konden we niet van te voren alle zaken exact inplannen.

WEEKVERSLAGEN Binnen Tenuki wordt er gewerkt met weekverslagen. Ook wij hebben, als zijnde echte werknemers, elke week een verslag ingeleverd. In dit verslag schreven wij wat we die week bereikt hadden en wat we gedaan hadden. Deze manier van zelfreflectie maakt je bewust van de dingen waar je mee bezig bent. Het is belangrijk om bepaalde leermomenten, kritiek, of doorgemaakte groei op een rijtje te zetten.

2.4

VERSIEBEHEER

Alle code, maar ook verslagen en diagrammen, werden tijdens het project door middel van Subversion beheerd. Op deze manier konden we niets kwijtraken, eventueel zelfs oudere bestanden terughalen en het belangrijkste: zorgeloos met meerdere mensen tegelijk aan hetzelfde bestand werken. Het werken met SVN (subversion) hebben we eerder gedaan tijdens projecten op de TU en was ons zeer goed bevallen. We hadden de mogelijkheid om de server te installeren bij Tenuki en onze eigen repository aan te maken, waar we alle data in op konden slaan. Bij Delphi wordt gewerkt met een versiebeheer tool genaamd TeamSource. Dit is dan ook de tool waar werknemers van Tenuki gebruik van maken als ze hun Delphi code willen beheren. Vanwege het feit dat wij ervaring hadden met SVN, het beheren van alle data (inclusief afbeeldingen en andere documenten) eenvoudig was en het een koppeling met Trac had, kozen we ervoor om SVN te gebruiken.

6

3.

PLANNING

In dit hoofdstuk wordt de planning van de stage behandeld. We zullen hier ingaan op de planning, zoals we die vooraf gemaakt en we gevolgd hebben. Een gevolg van het gebruik van XP bij onze stage is dat er vooraf geen gedetailleerde planning voor het hele project gegeven kan worden. Er wordt slechts een uitgebreide planning gemaakt per fase. We zullen de globale planning die we aan het begin hebben gemaakt, daarom een statische metaplanning noemen. Verder gaan we hier in op de planning die we per fase hebben gemaakt. Deze planning noemen we de dynamische iteratieplanning. Deze planning is dynamisch in de zin dat de planning van de nieuwe iteratie pas opgesteld wordt aan het eind van de vorige iteratie.

3.1

STATISCHE METAPLANNING

Hier wordt de globale planning beschreven, welke vooraf, in week 1 van het project is vastgesteld. Hierbij komt de nadruk te liggen op het doel, het ‘wat’ en niet zozeer het ‘hoe’. Opgemerkt moet worden dat de planning voor zowel het monitoringprogramma als het storingsregistratieprogramma parallel lopen. Later bleek dat dit bijzonder onrealistisch was. Hier echter later meer over. Voorbereidend werk: Week 1 Opzetten SVN Opzetten Project Management Systeem (Trac) Wegwijs worden binnen Tenuki Eerste inventarisatie van de opdracht Iteratie 0: Week 2 t/m 3 Werkwijze binnen Tenuki wat betreft monitoren/storingen in kaart brengen Schermen schetsen, voorleggen en feedback verwerken Duidelijk krijgen wat tot de basisfunctionaliteit van de programma’s moet behoren Iteratie 1: Week 4 t/m 5 Rompsysteem, waarin de basisfunctionaliteit is verworven Iteratie 2: Week 6 t/m 7 Feedback op Rompsysteem verwerken Werken naar Beta-versie Iteratie 3: Week 8 t/m 10 Feedback op Beta-versie verwerken Release versie uitbrengen

3.2

DYNAMISCHE ITERATIEPLANNING

Hier gaan we dieper in op de verschillende iteraties. Na elke iteratie wordt er voor de volgende iteratie een planning opgesteld.

7

ITERATIE 0 Het voorbereidende werk is gedaan, wat betekent dat we ons daadwerkelijk kunnen richten op de inhoudelijke kant van de stage. Week 2 (14 april – 17 april) Interviews afnemen Use-cases opstellen Schermen schetsen Database modeleren Laatste dag: Presenteren van verzamelde informatie Week 3 (21 april – 24 april) Feedback op use-cases en geschetste schermen verwerken Feedback op database model verwerken Basisfunctionaliteit (Rompsysteem) concreet op papier

ITERATIE 1 In de vorige iteratie is er vastgelegd wat er van ons wordt verwacht. In deze iteratie draait het er om deze verwachtingen voor het rompsysteem waar te maken. Week 4 (28 april – 1 mei) XML Convertors maken Database opzetten Schermen uitwerken in Delphi Week 5 (5 mei – 8 mei) Koppelen van code uit week 4 om het rompsysteem werkend te krijgen Export functie maken die XML als output geeft Laatste dag: Presenteren van het rompsysteem

ITERATIE 2 Aan de hand van de presentatie in week 5 zijn er een hoop zaken naar voren gekomen. Deze punten moeten verwerkt worden om tot een goede Beta-release te komen. Week 6 (12 mei – 15 mei) Aantekeningen van de commentaren op de presentatie verwerken User-sessies houden Basisfunctionaliteit afronden (inhalen uit vorige iteratie)

8

Week 7 (19 mei – 22 mei) Feedback uit user-sessies verwerken Graphische User Interfaces verbeteren (schalen, positionering, naamgeving) Rapportage storingssysteem naar Rich Text Format in plaats van XML Zoekfunctie uitbreiden

ITERATIE 3 Week 8 (26 mei – 29 mei) Verfijnen gebruiksvriendelijkheid / duidelijkheid Met voorstel komen voor koppeling van storingen en kennisbankartikelen Week 9 (2 juni – 5 juni) Koppeling maken tussen storingen en kennisbankartikelen Week 10 (9 juni – 11 juni) Software installeren op servers

9

4.

WAT MOETEN WE DOEN

In dit hoofdstuk onderzoeken we, geheel volgens de Tenuki werkwijze, het ‘wat’. Het is de bedoeling om samen met de klant, de gebruikers, op één lijn te komen en zodoende de juiste doelen te stellen. Allereerst wordt de huidige situatie in kaart gebracht en de context van de te maken applicaties bepaald. Door middel van interviews en gebruikersessies wordt er verder geanalyseerd wat belangrijk is voor de gebruiker. Dit hoofdstuk gaat globaal in op de zaken die we tijdens het project moesten realiseren. In hoofdstuk 6 behandelen we per iteraties de requirements.

4.1

CONTEXT

De applicaties die we maken kunnen ingedeeld worden in de categorieën preventief (monitoring) en reactief (storingsregistratie). De applicaties automatiseren en/of ondersteunen processen die voorheen handmatig gedaan werden. In deze paragraaf lichten we de context van de applicaties toe. Hieronder is de context van de applicaties samengevat in een diagram (zie figuur 2).

Figuur 2: Context van de applicaties.

MONITORING Het doel van monitoren is preventief onderhoud aan de servers en om pro-actief te kunnen handelen op mogelijke storingen. Er wordt namelijk op deze systemen gezocht naar symptomen die mogelijk voorafgaan aan een storing. Als er zulke symptomen waargenomen worden, dan moet er actie ondernomen worden. In paragraaf 4.2 wordt beschreven hoe de monitoring op dit moment nog wordt uitgevoerd. Dit proces maakt deel uit van een beheercontract dat Tenuki haar klanten aanbiedt. Door de monitoringen te automatiseren en de resultaten van de monitoringen centraal op te slaan, wordt het mogelijk om de rapportage hiervan te automatiseren. 10

STORINGSREGISTRATIE De storingsregistratie is reactief. Er wordt namelijk actie ondernomen op het moment dat er een storing binnenkomt. In paragraaf 4.2 wordt beschreven hoe storingsregistraties op dit moment nog worden aangenomen. Het verhelpen van storingen maakt deel uit van een onderhoudscontract dat Tenuki aan haar klanten aanbiedt. Doordat de storingsregistraties centraal opgeslagen worden, wordt het mogelijk om de rapportage van deze storingen te automatiseren.

RAPPORTAGE De rapportage van storingen en monitoringen maken deel uit van een beheer- en onderhoudscontract dat Tenuki met klanten heeft gesloten. Met de rapportages kan Tenuki aantonen dat zij actie heeft ondernomen bij storingsmeldingen. Op deze manier krijgen de klanten inzicht in de service waar zij voor betalen. Daarnaast kunnen de rapportages aansturen op het aanpassen van software. Deze aanpassingen vallen dan onder correctief onderhoud (bijv. het debuggen van software) of zelfs adaptief onderhoud (het wijzigen of toevoegen van functionaliteit). Bij het correctief onderhoud wordt zelfs nog onderscheidt gemaakt tussen een ‘workaround’ en een ‘fix’. Een workaround is gericht op het zo snel mogelijk kunnen hervatten van de service. Vaak is het herstarten van processen of een geheel systeem voldoende. Af en toe komt het voor dat wordt overgeschakeld op een fallback-server, die tijdelijk de taak van de main server over kan nemen. Om een probleem daadwerkelijk op te lossen moet vaak verder gekeken worden. Dat kan resulteren in correcties en/of adapties van de software. Het uitvoeren van een ‘fix’ kost veel meer tijd en deze heeft ook weer een (acceptatie)test tot gevolg. De storingsrapportages ondersteunen de opdrachtgever in het aangeven van prioriteiten tussen de verschillende punten.

4.2

HUIDIGE SITUATIE

In deze paragraaf geven we een globaal beeld van hoe processen binnen Tenuki verliepen voordat de door ons ontwikkelde applicaties in gebruik zijn genomen. De subparagrafen kunnen gelezen worden als samenvatting van onze interviews met de gebruikers van de applicaties.

MONITORING Bij Tenuki zijn er twee processen die zich bezighouden met het detecteren en alarmeren bij storingen. Hoewel onze opdracht niet ingaat om het alarmeringsproces, nemen we hier toch een kleine uitleg over dit proces op, zodat ook de context van onze opdracht duidelijker wordt. In deze subparagraaf zullen we eerst behandelen hoe het monitoringproces momenteel verloopt. Daarna zullen we een beknopte uitleg geven over het alarmeringssysteem, dat luistert naar de naam Hector.

MONITORINGPROCES Om te kunnen monitoren moet er verbinding gemaakt kunnen worden met de verschillende te monitoren servers. Hiervoor moet er eerst een VPN verbinding opgezet worden. Wanneer dit is gedaan wordt het programma Putty opgestart. Dit is een Windows client om onder andere SSH verbindingen te maken. Wanneer Putty is geopend moeten er een ip-adres, een gebruikersnaam en een wachtwoord worden ingevuld. Dit proces herhaalt zich voor iedere server en is dus een tijdrovend karwei.

11

Wanneer er eenmaal verbinding is gemaakt met de server wordt er een programmaatje uitgevoerd, die als platte tekst een overzicht geeft van de huidige status van de server. Dit omvat gegevens van de volgende onderdelen: Harde schijf gebruik Processor gebruik Geheugen gebruik Verbonden gebruikers Ook worden er op een enkele server nog wat log-bestanden gecontroleerd om te kijken of kritieke processen, zoals websites en kaartapplicaties, recent nog actief waren. Op elke server zijn dit uiteraard weer andere bestanden. Verder moet er op enkele servers gecontroleerd worden of bestanden met meetlusdata, ook wel ady-bestanden, recent nog zijn bijgewerkt. Ook worden er monibas-bestanden en de routeserver-exportbestanden gecontroleerd op actualiteit en inhoud. Deze uitvoer van het programma wordt vergeleken met de vorige uitvoer om zo te kijken of er veranderingen zijn die mogelijk tot problemen kunnen leiden.

HECTOR Voor de volledigheid zullen we hier ook een uitleg geven over Hector. Dit systeem zit namelijk precies tussen onze opdrachten in en alarmeert als hij een storing tegenkomt. Het monitoringproces heeft als doel stroringen te voorkomen en het storingproces verwerkt eenmaal voorgekomen storingen. In de afbeelding hieronder is dit nog eens schematisch weergegeven.

Monitoring

Hector

Storingrapportage

Figuur 3: De keten van applicaties

Momenteel wordt er bij Tenuki gewerkt met de eerste versie van het Hector bewakingssysteem. Hector bewaakt en gaat correctief te werk. Bij het VCNL staan verschillende machines die gezamenlijk verschillende services aanbieden, zoals: File-informatie Reistijdinformatie Minuutbestanden (.ady) Wegwerkzaamheden Route-informatie Hector alarmeert systeembeheerders als een systeem niet doet wat het behoort te doen. Je kunt hierbij denken aan een pakketje dat verstuurd wordt en binnen een bepaalde tijd antwoord terug verwacht. Mocht dat antwoord niet op tijd terugkomen, dan zal er een alarm af moeten gaan. Een alarm kan zijn in de vorm van een e-mail of een sms-bericht.

12

Het huidige systeem (Hector v1) werkt met het Simple Network Management Protocol (SNMP). Dit protocol verkrijgt informatie van systemen en verbindingen. SNMP werkt met UDP. Het UDP protocol is connectieloos (er wordt geen expliciete verbinding opgezet) en onbevestigd (je zal nooit weten of een bericht is aangekomen of niet). Hector v1 controleerde systemen. Binnen het VCNL is er echter sprake van ketens. Wanneer 1 systeem een fout in een keten veroorzaakte, resulteerde dit in fouten in systemen die later in de keten zitten. Voor elk systeem werd er een alarm af gegeven, terwijl de fout slechts bij een enkele machine lag. Het werd dus ook tijd voor een tweede versie van Hector (v2) die ketens kon gaan bewaken. Hector v2 heeft de volgende doelen: 1. 2. 3.

Betere ondersteuning bij het lokaliseren van het fout veroorzakende systeem Betere classificatie van storingen in de keten Beschikbaarheidsrapportages op service niveau

Dit tweede systeem werkt met het bus-idee. Systemen die informatie willen kunnen zich ‘inschrijven’ (subscribe) bij de bus en verkrijgen informatie als deze zich aandient (publish). Het aandienen gebeurt redundant en als een publisher uitvalt, kan deze makkelijk vervangen worden door een andere. Hierdoor blijft het systeem werken. Er wordt melding gemaakt van het feit dat er een publisher uit is gevallen en dat probleem kan vervolgens opgelost worden terwijl het systeem blijft draaien.

STORINGSREGISTRATIE Per week krijgt Tenuki ongeveer tien storingsmeldingen binnen. Meestal worden deze storingen gemeld via de telefoon, maar het komt ook voor dat er storingen mondeling of via email gemeld worden. Als er een storing geregistreerd moet worden, opent de medewerker van Tenuki het Windows programma ‘Kladblok’ ook wel bekend als ‘Notepad’. Daarin wordt volgens een vast stramien de storing opgeschreven. De opmaak en volgorde van de data die getypt wordt, is meestal hetzelfde. Sommige velden zijn optioneel en worden in sommige registraties achterwege gelaten. De volgende velden komen voor in een storingsregistratie: Probleem naam: dit bestaat uit de naam van het systeem waar de storing zich voordoet, en een probleem omschrijving in enkele woorden. De datum en tijd van melding. De naam van de persoon die de storing gemeld heeft. De naam van de persoon die de storing behandeld heeft. Het probleem, hierin staat de probleemomschrijving zoals deze gemeld wordt. Deze omschrijving is niet per definitie juist, omdat de persoon die de storing meldt niet altijd tot voldoende informatie kan beschikken om een goede interpretatie van het probleem te geven. De situatie, de omschrijving van het probleem zoals deze wordt geconstateerd door de Tenuki werknemer. De ondernomen acties, bij iedere actie wordt ook een tijd opgeschreven. Het vervolg, hierin worden acties opgenomen die na het oplossen van de storing nog gedaan zijn. Opmerkingen, hierin worden opmerkingen geschreven. Deze opmerking is soms gericht aan de klant, maar af en toe ook aan andere medewerkers van Tenuki. Het einde, dit is de tijd waarop de storing is verholpen en teruggemeld is aan de klant. Het kan voorkomen dat er ook een naam bij vermeld wordt. Als dat het geval is, dan is degene die de storing heeft teruggemeld aan de klant iemand anders dan degene die de storing behandeld heeft. Een storingsregistratie wordt opgeslagen als .txt bestand. In de naam van het bestand staan de datum en tijd van de registratie en de naam van het systeem waarop de storing zich voordeed. Alle storingsregistraties van een maand worden in dezelfde map opgeslagen. 13

De registratie van een storing neemt weinig tijd in beslag. Het kost echter veel tijd en geduld om van deze registraties een rapportage te maken.

STORINGSRAPPORTAGE De storingsrapportage is het proces van het melden aan de klant welke storingsmeldingen er zijn geweest en wat voor acties ondernomen zijn. Momenteel is dit een tijdrovend proces. De storingsregistraties zijn allemaal opgeslagen in aparte .txt bestanden zonder enige opmaak. Het bundelen en opmaken van de registraties in Microsoft Office Word gebeurt met de hand. Elke twee á drie dagen wordt er een samenvatting van de storingsmeldingen in die tijd verstuurd naar klanten. Sommige registraties worden deels gecensureerd, omdat sommige informatie die in de .txt bestanden staan, niet voor de klant bestemd is. Deze ‘tussenrapportage’ voor een periode van 2 á 3 dagen wordt per email naar de contactpersoon van een klant gestuurd. In de email staat een overzicht van storingsmeldingen gegroepeerd per dag. Daarnaast wordt een ingepakt tekst bestand als attachment meegestuurd met daarin de gecensureerde registraties. Naast de tussenrapportages zijn er ook de vier wekelijkse rapportages. Deze rapportage bestaat uit een inhoudsopgave met daarin de storingsmeldingen die per systeem zijn geregistreerd en verholpen. Na deze inhoudsopgave volgen de (mogelijk gecensureerde) storingsregistraties. Hierin worden de storingsregistraties van een periode van vier weken gebundeld. De vier wekelijkse rapportage wordt hardcopy naar de klant verstuurd.

4.3

USE CASES

Het duidelijk in kaart brengen van de gebruikersituaties die zich voor kunnen doen is essentieel in het ontwerpen van de juiste applicatie. Wij hebben usecase diagrammen gebruikt om duidelijk te krijgen welke actoren er te onderscheiden zijn, en welke taken ondersteund moeten worden.

MONITORING De werknemer in figuur 4 is de enige actor die gebruik maakt van de monitoringapplicatie. Alle acties die op de cliënt-applicatie uitgevoerd worden, zijn acties van de werknemer. De start en stop monitoring acties zorgen ervoor dat het monitoringproces voor een desbetreffende server gestart en gestopt kan worden. Hiernaast kan er een overzicht gegeven worden van het monitoringproces van een bepaalde dag en een bepaald tijdstip.

14

Figuur 4: Use Case Diagram Monitoring

De monitoring moet gedaan worden door gebruikers. Deze gebruikers kunnen in het systeemworden toegevoegd, gewijzigd en verwijderd. Bij aanvang van het monitoringproces zal de gebruiker zijn naam selecteren, zodat later teruggevonden kan worden wie de monitoring op dat moment heeft uitgevoerd. Aan elke monitoring van een server kunnen opmerkingen worden toegevoegd. Mocht een server bepaald gedrag vertonen, of op een bepaald moment niet relevant meer zijn, kan die toegevoegd, gewijzigd, bekeken of verwijderd worden. Uiteraard is er de mogelijkheid om servers te beheren (toevoegen, wijzigen en verwijderen). Daarnaast kan de werknemer de rapportages exporteren en opslaan op een bepaalde locatie.

STORINGSREGISTRATIE EN STORINGSRAPPORTAGE De drie actoren die we in figuur 5 onderscheiden kunnen alle taken uitvoeren die in het usecase diagram staan. In dit ‘nadruk’ usecase diagram geven we aan welke taken belangrijk zijn voor de verschillende actoren die met de storingsregistratie en storingsrapportage applicatie gaan werken. De ‘expert’ is de medewerker van Tenuki die zelfstandig storingen kan registreren en op kan lossen. Voor deze actor wordt de nadruk gelegd op het invoeren van storingsregistraties en het bewerken van eerder geregistreerde storingen. Wellicht kan het voorkomen dat een ‘leerling’ of iemand anders een storing heeft aangenomen van een klant terwijl deze persoon niet zelf in staat is de storing daadwerkelijk op te lossen. In dat geval zal de ‘expert’ de onopgeloste storingsregistratie tijdens het oplossen moeten bijwerken.

15

De ‘leerling’ is de medewerker die nog niet zoveel ervaring heeft met het oplossen van storingen. In hun geval kan het handig zijn om te zoeken naar storingen die lijken op de op te lossen storing. De administratief medewerker zal zich vooral bezig houden met de rapportage. Daarom is het voor deze actor belangrijk dat we het zoeken, samenvatten en exporteren van storingen ondersteunen met de applicatie.

Figuur 5: 'Nadruk' Usecase Diagram Storingsregistratie en rapportage.

4.4

GEBRUIKERSSESSIES

Een manier die we gebruikt hebben tijdens de analyse om het ‘wat’ duidelijk te krijgen, is het houden van gebruikerssessies. Deze sessies hebben we met individuele gebruikers gehouden, maar ook met meerdere gebruikers tegelijk. De individuele gesprekken vonden vooral in de eerste twee weken (in iteratie 0) plaats toen we het ‘wat’ duidelijk moesten krijgen. De groepsessies hebben we vooral gehouden na iedere iteratie (behalve de laatste). Deze groepsessies waren meer gericht op het afstemmen met de gebruiker dat de oplossing (het ‘hoe’) nog steeds overeenkwam met wat er uiteindelijk bereikt moest worden (het ‘wat’). In termen van de Tenuki-werkwijze deden we aan ‘verwachtingsmanagement’.

16

De gebruikerssessie waren goed mogelijk, omdat de gebruikers altijd in hetzelfde pand aanwezig waren. Hierdoor konden we gemakkelijk vragen aan hen stellen en kregen we direct feedback op voorstellen. Het doel van de gebruikerssessies was niet alleen maar het vergaren van informatie over het te ontwerpen systeem. Het was ook een manier om te communiceren met de gebruiker of wij hun opmerkingen en beschrijvingen van werkprocessen goed hadden geïnterpreteerd. Daarnaast is het een manier om aan verwachtingsmanagement te doen. Dit is eigenlijk een manier om de gebruiker ‘rijp’ te maken voor een nieuwe werkwijze (of applicatie/systeem). Door de gebruiker bij de ontwikkeling te betrekken, krijgen ze de kans om te wennen aan de vernieuwing, maar ook om zelf sturing te geven aan de werkwijze. Vanuit de Tenuki-werkwijze wordt de gebruiker vroegtijdig bij het proces betrokken omdat op deze manier de kans kleiner wordt dat er iets gemaakt wordt wat niet de bedoeling is. Ook geeft de gebruikersfeedback informatie over de denk- en werkwijze van de gebruiker. Dit is belangrijk voor de ondersteuning die we moeten gaan bieden, maar dit levert ons ook belangrijke aanwijzingen voor het maken van de GUI. Bovendien krijgt de gebruiker het gevoel samen aan de applicatie te werken. Dit levert draagvlak en goodwill op. Tot slot wordt het voor de gebruiker een stuk duidelijker wat het eindresultaat wordt. Voor aanvang van individuele gebruikerssessies bereidden we vragen voor en maakten we wat schetsen of screenshots van schermen. Deze schetsen hielpen ons bij het communiceren met de gebruiker. De gemeenschappelijke taal van de afbeeldingen vormt hierbij de brug tussen informatica-termen en het domein van de gebruiker. Bovendien kregen de gebruikers een idee van de interface en konden onduidelijkheden aangeven, maar ze konden ook direct zien wat ze misten. Dit hielp ons dus zoveel mogelijk informatie van de gebruiker te krijgen. Bij de centrale gebruikerssessies waren meerdere gebruikers aanwezig, en meestal waren er ook leidinggevenden bij (David, Mariska). We gebruikten een beamer om beelden te tonen aan degenen die deelnamen aan de sessie. In het begin van de stage gebruikten we screenshots van schermen, later konden we ook een werkende applicatie laten zien. Tijdens deze gebruikerssessies gaven we eerst een inleidend verhaal over wat we in de afgelopen iteratie volbracht hadden en wat we in de komende iteratie wilden volbrengen. Daarna toonden we de schetsen of voerden we taken uit met de applicatie. Hierover ontstond dan een discussie met de gebruikers. We bootsten een situatie na, bijvoorbeeld de melding van een storing. Er moest dan een storing geregistreerd worden met de storingsregistratie applicatie. We zagen dan direct wat onze applicatie nog miste, maar ook wat handig was en wat we goed gedaan hadden. Alle aanwijzingen namen we mee voor de volgende iteratie. Bij de aanwijzingen die we kregen is het belangrijk om onderscheid te maken tussen aanwijzingen van gebruikers en aanwijzingen van David of Mariska. De laatste zijn namelijk de opdrachtgever. Uiteindelijk bepalen zij welke aanwijzingen van gebruikers ook daadwerkelijk aangepakt moeten worden. Daarom analyseerden we na de sessies de verkregen informatie en bespraken we de resultaten met David en/of Mariska. In sommige gevallen bleken aanwijzingen van gebruikers niet relevant voor onze applicaties en lieten we die aanwijzingen varen. Goedkeuring van aanwijzingen door de opdrachtgever is dus erg belangrijk bij de informatie die uit gebruikerssessies wordt verkregen.

4.5

EVALUATIE CONTROLES

In deze paragraaf zullen we een deel van de huidige controles langslopen en kijken of het nuttig is om deze controles ook in ons programma op te nemen. We zullen eerst een beeld schetsen van de controles die het huidige programma uitvoert, waarna we deze controles langslopen. Aan het eind zal er geconcludeerd worden of de huidige controles inderdaad volstaan.

17

Momenteel worden de volgende gegevens op de servers gemonitord: Geheugengebruik per applicatie Vrij werkgeheugen Vrije harde schijfruimte per partitie Vrije inodes per partitie Afnemers Verder wordt per server de naam, type en het ip-adres van de server vermeld. In het huidige proces worden deze gegevens uit een configuratiebestand gelezen die op de server staat. Er wordt zelf een naam gegeven aan de server, omdat de computernaam misschien in de loop der tijd zou kunnen veranderen, niet gezet kan zijn of totaal nietszeggend is. Verder wordt er ook een tijdstempel meegegeven, zodat gezien kan worden wanneer de monitoring is uitgevoerd. De bovenstaande gegevens zijn de gegevens die door het huidige programma worden verstuurd. Er moet wel opgemerkt worden dat er veel meer controles zijn die worden uitgevoerd. We gaan hieronder per onderdeel bespreken waarom het nodig is dat die specifieke eigenschap van een server gecontroleerd wordt.

GEHEUGENGEBRUIK PER APPLICATIE Sommige applicaties hebben problemen met geheugen lekken (memory leaks). Het is voorgekomen dat een applicatie vreemd gedrag ging vertonen op het moment dat deze te veel geheugen aan het gebruiken was. Hierdoor is het nodig om voor bepaalde applicaties te kijken hoeveel geheugen ze aan het gebruiken zijn en of dit stabiel of juist toenemend is. De te controleren applicaties verschillen uiteraard per server. Het kan dus zijn dat een applicatie niet gecontroleerd wordt op de ene server, maar wel op de andere.

VRIJ WERKGEHEUGEN Verder is het ook nuttig om te kijken naar de totale beschikbare ruimte van het werkgeheugen. De meest kritieke applicaties worden apart gemonitord. Echter is het ook belangrijk om te kijken naar het totaal plaatje. Het kan zijn dat er een applicatie die niet gecontroleerd wordt geheugen lekt, of dat het totaal van applicaties te veel geheugen gebruikt. Wanneer het werkgeheugen volledig vol is, heeft dit heel veel impact op het systeem. Wanneer het werkgeheugen vol is, gaat het OS namelijk geheugen swappen naar de harde schijf. Het behoeft geen uitleg dat een harde schijf vele malen langzamer is dan werkgeheugen. Dit heeft nadelige gevolgen voor de prestatie van een systeem. Zo kan het zijn dat bepaalde tijdkritieke applicaties niet meer op tijd kunnen reageren, met alle gevolgen van dien.

VRIJE HARDE SCHIJFRUIMTE PER PARTITIE Het huidige systeem controleert ook de vrije harde schijfruimte van een aantal belangrijke partities. Sommige servers schrijven een hoop logbestanden weg en wanneer deze niet op tijd opgeruimd worden, kan het voorkomen dat een partitie volloopt. Wanneer dit gebeurd kunnen bepaalde processen of zelfs heel de server vast lopen. Ook zal er vrijwel zeker dataverlies optreden. Dit zijn uiteraard zaken die niet gewenst zijn.

18

VRIJE INODES PER PARTITIE De betekenis en het nu van i-nodes is vaak niet bekend. Vandaar dat we hieronder een deel van de Wikipedia uitleg hebben opgenomen: “Een i-node is een manier om bestanden op te slaan op een harddisk. De naam komt van index-node. Aangezien grote bestanden in kleine blokjes (zogenaamde sectoren) moeten worden verdeeld, is er een administratie nodig welke sectoren door een bestand in gebruikt zijn.” Wanneer er geen i-nodes meer beschikbaar zijn kunnen er geen bestanden meer weg worden geschreven. Ook dit heeft negatieve effecten voor de prestatie en stabiliteit van een server. In het verleden zijn er problemen geweest met i-nodes. Hierna is de controle op i-nodes in het huidige programma opgenomen. Aangezien het in de toekomst ook nog voor kan komen dat dit problemen geeft, is het dus een nuttige controle om te behouden.

AFNEMERS Bij de distributieservers wordt er ook gecontroleerd welke afnemers wel/niet verbonden zijn. Het is belangrijk te weten of alle belangrijke klanten verbonden zijn, zodat wanneer dit niet het geval zou zijn, we ze op tijd kunnen waarschuwen.

CONCLUSIE Nu we alle huidige controles hebben nagelopen, kunnen we vaststellen dat deze controles inderdaad kunnen helpen om fouten te voorkomen. Het is dus nuttig om deze controles te behouden. Bij veel van deze controles kan redelijk goed voorspeld worden dat een bepaalde eigenschap in de toekomst fouten gaat geven. Ter illustratie is het langzaam vollopen van een harde schijf heel goed te volgen. Wanneer deze bijna vol is, weet je dat er actie ondernomen moet worden om storingen te voorkomen.

VOORSTELLEN Er is ons verder ook gevraagd om na te denken over eventuele extra controles die storingen zouden kunnen voorkomen. We konden echter weinig nieuwe controles verzinnen en hebben ons voornamelijk gericht op het automatiseren van de huidige controles. Dit om ook de opdracht niet al te groot te maken. Hieronder is een overzicht te vinden van de extra controles die we hadden bedacht. De controle wordt kort toegelicht en er is te lezen of we deze controle uiteindelijk wel of niet zullen meenemen in ons programma. De extra controles die we ten opzicht van het oude programma hadden bedacht zijn: Load Responsetijd Wanneer de load op een bepaalde server steeds vaker te hoog ligt, zal dit negatieve effecten hebben op de prestatie van die server. Wanneer er tijdkritieke applicaties draaien kan een hoge load een tegen zijn dat deze applicaties niet op tijd zullen gaan reageren. Wanneer de load consequent hoog blijft, kan er worden geadviseerd om een snellere server aan te schaffen en te installeren. Dit leek ons dus wel een goede controle om ook toe te voegen.

19

We hebben ook gedacht om de responstijd van een server bij te gaan houden. Echter uit gesprekken met de gebruiker bleek dat dit niet te controleren valt. We hebben via het Internet verbinding met de servers en er zijn heel veel factoren die de snelheid van de verbinding kunnen beïnvloeden. Hierdoor kan er dus niets zinnigs gezegd worden over de responsetijd. Het opnemen van een dergelijke controle is dus niet nuttig en zullen we dus ook niet doen.

4.6

ALGEMEEN ONTWERP

Tijdens heel het ontwerpproces hebben we een grof beeld gekregen waar we uiteindelijk willen uitkomen. In deze paragraaf wordt beschrijven hoe we aan het begin van het project dachten dat de applicaties er uit zouden komen te zien. Deze beschrijven de applicaties hier apart.

MONITORINGSYSTEEM Na het zien van enkele monitoringen en het zien van de rapporten zijn we dit gaan verwerken tot een idee wat er precies moest gebeuren. Dit idee hebben we besproken en hier zijn de volgende dingen uit gekomen. Er gaat een desktop applicatie gemaakt worden welke automatisch verbinding maakt met de opgegeven servers. De resultaten worden per server in een scherm weergegeven. Dit scherm heeft een linker en een rechter kolom. In de linker kolom tonen we de huidige waarden en in de rechter kolom tonen we waarden van een vorige monitoring, zodat deze met elkaar vergeleken kunnen worden. De volgende gegevens zullen hier te vinden zijn: Vrij werkgeheugen Gebruikt geheugen per applicatie Vrije schijfruimte Verbonden afnemers Indien gewenst zullen hier nog extra controles aan toegevoegd kunnen worden. Verder zal bij de huidige situatie de tijd van de laatste waarde in een log bestand, of de laatste paar regels van een log bestand te zien zijn. Ook kunnen er per server opmerkingen worden getoond en bijgewerkt. Dit kan bijvoorbeeld handig zijn om aan te geven dat er recent wijzigingen zijn waar iemand op moet letten. Wanneer alle servers zijn doorlopen kan er nog gecontroleerd worden op de .ady bestanden en op de tijd waarop belangrijke XML-bestanden voor het laatst zijn bijgewerkt. Verder kan TITP misschien nog geïntegreerd worden. Heel dit proces is volledig vrij te configureren. Zo kan er per server worden aangegeven wat het ip-adres is en met welke gebruikersnaam en wachtwoord er ingelogd moet worden. Verder kan er aangegeven worden welke controles er uitgevoerd moeten worden.

WORKFLOW Het programma wordt gestart en er kan gekozen worden of alle servers gemonitord moeten worden of slechts enkele. Eventueel kan de volgorde worden aangepast. Wanneer de servers zijn geselecteerd die gemonitord moeten worden, kan er begonnen worden met de monitoring. Wanneer het programma de gegevens van de servers heeft opgehaald zal de gebruiker het overzichtsscherm te zien krijgen. Op dit scherm zal de applicatie waarschuwingen geven. Wanneer er een waarschuwing wordt gegeven is het nuttig voor de gebruik om eens goed naar de betreffende waarde te kijken. Verder kunnen in details de status van de servers worden bekeken. Verder is er een mogelijkheid om de resultaten op te slaan. 20

STORINGSREGISTRATIESYSTEEM Het systeem dat wij voor ogen hadden zou de drie verschillende actoren ondersteunen in hun werk. De expert moet snel en gemakkelijk een storingen kunnen rapporteren, de leerling moet op enige manier hulp krijgen bij het oplossen van storingen en de administratieve medewerker moet wat betreft rapporteren tijdswinst kunnen boeken. Onze plannen hebben we besproken, vastgelegd en worden in de volgende paragrafen beschreven. Er wordt een desktop applicatie gemaakt welke via XML over TCP communiceert met een Windows Service. Deze service, en alleen deze service, praat met de database. De applicatie maakt een onderscheid tussen de drie verschillende actoren, welke voor de applicatie zelf in tweeën gedeeld worden. Aan de ene kant de expert, aan de andere kant de leerling en de administratie. Voor de expert geldt dat het invoeren van een storing het belangrijkst is. Deze krijgt dus bij het opstarten van de applicatie direct het formulier te zien voor een nieuwe storingsregistratie. Voor de leerling en de administratie is het handiger om in het overzichtsscherm te starten. Van hieruit zijn de functies die zij primair nodig hebben het best te bereiken. Het invullen van een nieuwe storing moet vooral snel gebeuren. Wanneer we weinig veranderen ten opzichte van de huidige tekstbestanden, zal de werkwijze weinig veranderen. De herkenbaarheid zal dus bijdragen aan de snelheid van het invullen van een storing. We proberen te allen tijden ervoor te zorgen dat overgang van het snel invullen in Notepad niet vertraagd wordt door het formulier. Voor de leerling actor hebben we een zoekfunctie in ons hoofd. Een functie die helpt zoeken naar overeenkomstige storingen. Op deze manier zou een oude registratie kunnen helpen bij het oplossen van een nieuwe melding. Echter, de acties die bij de storingen zijn ondernomen, zijn vaak kort en bondig opgeschreven. Voor iemand die er van moet leren, hebben de storingsregistraties op deze manier vrij weinig waarde.

21

5.

ARCHITECTUUR

In dit hoofdstuk gaan we in op de architectuur van het systeem. In fase 0 hebben we voor beide systemen al een globaal beeld kunnen vormen van het doel waar de naar toe moeten werken. Hoe we naar dit doel toe gaan werken wordt in dit hoofdstuk behandeld. We zullen de keuze voor een client/server architectuur behandelen. Hiernaast behandelen we de communicatie en waarom we de communicatie laten verlopen zoals we nu doen. Ook gaan we in op het database ontwerp voor beide systemen. We zullen ingaan op het proces dat we hebben doorlopen bij deze ontwerpbeslissingen en we zullen voor- en nadelen van onze keuzes afgaan.

5.1

CLIENT/SERVER-SIDE

Bij beide systemen is gekozen voor een client/server architectuur. In deze paragraaf behandelen we deze keuze en geven we aan waarom we hiervoor gekozen hebben.

MONITORING De keuze voor een client/server-architectuur lag bij het monitoringsysteem voor de hand. Het gaat tenslotte om clients die allemaal andere servers moesten monitoren. Aangezien we ook met de client/serverarchitectuur ervaring hadden, konden we al snel het volgende deployment diagram tekenen:

Figuur 6: Deployment diagram monitoring

De database bevindt zich op een aparte server en enkel de client maakt verbinding met deze database. Dit is zo gekozen om alles consistent te houden, aangezien er verschillende client-applicaties draaien. De server krijgt een request binnen van de client en verstuurt zijn gegevens terug naar de client. Hier worden de gegevens vervolgens verwerkt en weggeschreven naar de database.

GEDETAILLEERD ONTWERP Het ontwerp van de onderdelen (client, server en rapportage), is gegaan in overleg met Tenuki. Binnen Tenuki is een bepaalde manier van ontwerpen ontstaan, die veelvuldig gebruikt wordt. Dit heeft zijn voordelen, zeker voor het OS-onafhankelijk ontwikkelen. Het ontwerp is te zien in figuur 7:

22

Figuur 7: ontwerp monitoringsysteem

De Lib map is erg centraal en belangrijk. Hierin bevinden zich alle klassen die gebruikt worden door het programma, tevens bevat het de XML-converters. Deze XML-converters zijn zeer belangrijk voor het versturen van de gegevens tussen de client en server. De database wordt ook alleen rechtstreeks benaderd via de database converter, die te vinden is in de Lib directory. De serverconstructie is tevens zeer belangrijk om te benoemen. In de hoofdmap bevinden zich alle stukken code die op elk OS kunnen draaien. Tevens bevindt zich hier een abstracte monitoring module. Deze module bevat alle functies die nodig zijn voor de monitoring (ophalen harddisk ruimte bijv.), maar zonder implementatie. Onze server kan tegen deze abstracte klasse praten, zonder er bij na te hoeven denken onder welk OS het programma draait. De OS afhankelijke bestanden (implementatie van de abstracte klasse) bevinden zich in hun eigen map. Deze klassen implementeren de abstracte klasse en vullen deze functies. Op deze manier hebben we één server geschreven die onder Windows en Linux te compileren is. Het is tevens belangrijk om op te merken dat er twee verschillende versies voor de Linux daemon zijn. Er is een versie voor een Linux 2.4 kernel en een versie voor de Linux 2.6 kernel. Het enige verschil zit hem in de wijze waarop de applicatie gestart wordt (met verschillende objecten uit de Tenuki library). Waarom het programma niet goed functioneerde op de Linux 2.4 kernel, is ons niet duidelijk geworden.

STORINGSREGISTRATIE Er is gekozen voor een 3-tier architectuur. De clientapplicatie communiceert met de business logic op de server, welke weer communiceert met de database (zie figuur 8). De keuze voor deze architectuur is naar Tenuki toe voornamelijk verantwoord door te zeggen dat het ons leuk, maar vooral ook leerzaam, leek het op deze manier te doen. Een extra uitdaging als het ware. De voordelen van bijvoorbeeld een serverside push mogelijkheid hebben we in ons achterhoofd gehouden.

23

Figuur 8: Deployment diagram storingsregistratie

GEDETAILLEERD ONTWERP Als we iets gedetailleerder kijken naar de verschillende bestanden die door de applicatie worden gebruikt, dan krijgen we een plaatje zoals in figuur 9 is weergegeven. Hieruit wordt duidelijk dat er een centrale map is, Lib, waarin belangrijke klassen voor de applicaties (zowel client als server) zijn opgenomen. Ook zijn hier de verschillende convertors te vinden. Aan de client-side zijn er twee applicaties die op een klein punt verschillen: het opstarten. In het geval van de StoringClient wordt er opgestart met het storingen overzichtsscherm. De RegistratieClient opent bovenop het overzichtsscherm direct het formulier om een nieuwe storingsmelding af te handelen. Zoals in het figuur te zien is, bestaan er een WinDev en WindowsService applicatie. De eerstgenoemde wordt gebruikt tijdens de ontwikkeling en heeft een simpele grafische userinterface om bijvoorbeeld debuginformatie te printen. De WindowsService is de uiteindelijke service die aan de serverkant draait. Deze service luistert naar een bepaalde port en krijgt de XML requests van client applicaties binnen. Vervolgens gebruikt de service enkele klassen uit de ‘Lib’ om met de database te communiceren en om XML naar de client terug te sturen.

24

Figuur 9: ontwerp storingsregistratie

5.2

COMMUNICATIE

In deze paragraaf wordt verteld hoe de communicatie tussen client en server verloopt. Voor het storingrapportageprogramma zagen we niet heel veel opties en was de keuze redelijk snel gemaakt. Echter voor het monitoringprogramma zijn er vele manieren om de communicatie te laten verlopen. Hieronder wordt een overzicht gegeven van de verschillende mogelijkheden en kiezen we uiteindelijk een communicatie manier.

SIMPLE NETWORK MANAGEMENT PROTOCOL Simple Network Management Protocol (SNMP) is een protocol dat veel gebruikt wordt voor de monitoring van servers. SNMP services kunnen zo ingesteld worden dat ze een bericht sturen wanneer een resource een bepaalde threshold bereikt. Bijvoorbeeld als er nog maar 200Mb vrij is op de server. Echter kan via dit protocol ook de huidige situatie worden opgevraagd en hier zouden wij dan gebruik van gaan maken. SNMP wordt reeds gebruikt in de eerste versie van het Hector systeem. In de tweede versie van Hector wordt echter geen gebruik meer gemaakt van SNMP. Dit omdat Hector v2 een keten bewaakt en niet meer onafhankelijke systemen. Een groot nadeel van SNMP is echter dat de pakket grootte beperkt is. Hierdoor zou het in de toekomst voor kunnen komen dat de data die terug gestuurd moet worden van de server naar de client, niet meer in het pakket past. Voordelen: SNMP services staan al geïnstalleerd op de servers Nadelen: Beperkte pakket grootte

SSH EN RDP Momenteel wordt er handmatig verbinding gemaakt met verschillende Linux servers over SSH en met een enkele Windows server met behulp van het RDP protocol. Als er verbinding is met de servers wordt er een monitoringprogramma gestart, dat de gegevens terug geeft.

25

We hebben er aan gedacht om dit proces als het ware te spiegelen in ons ontwerp, waarbij we dus heel dicht bij de huidige werkwijze zouden blijven. Dit proces automatiseren is mogelijk over SSH, omdat er automatisch verbinding gemaakt kan worden met een server. Als de verbinding tot stand is gebracht kunnen we een programma uitvoeren wat gegevens terugschrijft naar de console. Deze kunnen we dan afvangen en verder verwerken. Via RDP is dit echter niet mogelijk. Het is daar niet mogelijk om op een console- achtige manier verbinding te maken met de server en zo gegevens terug te krijgen. Je zit dan altijd aan een grafisch schil vast. Waardoor het dus lastig, zo niet onmogelijk, is om dit als basis te gebruiken in ons programma De enige manier waarop we met een Windows server een veilige verbinding kunnen maken en output terug kunnen krijgen, is door het installeren van een SSH server op de Windowsservers. Echter geeft dit redelijk wat werk, omdat er op elke server weer een extra server proces geïnstalleerd moet worden en onderhouden. Voor Linux is er dus een goede oplossing, voor Windows niet. We zijn echter op zoek naar een oplossing die voor zowel Windows als Linux servers te gebruiken is, omdat dit onder andere makkelijker te onderhouden is. Voordelen: SSH is een veilige verbinding Momenteel gebeurt alles al over SSH voor de Linux servers Nadelen: SSH installeren op Windowsservers levert veel overhead

HTTP Het idee van de communicatie over HTTP is om een script op een webserver te zetten die, wanneer deze benaderd wordt, de benodigde gegevens teruggeeft. Dit zou dan in bijvoorbeeld XML kunnen gebeuren. Voordelen: OS onafhankelijk script mogelijk Nadelen: Redelijk veel overhead, door installatie volledige webserver Door het installeren van een webserver ben je kwetsbaar voor hacks op deze webserver

EIGEN DAEMON Een andere mogelijk is om een eigen daemon of service te maken die gedraaid wordt op de servers die gemonitord moeten worden. Deze daemon zal een TCP server socket hebben en we zullen daar via een eigen XML protocol mee kunnen communiceren. Een voordeel van deze mogelijkheid is, dat er binnen Tenuki al componenten aanwezig zijn om een TCP server socket op te zetten die XML kan versturen. De client maakt dan verbinding met onze daemon, die op zijn beurt in XML de status van de server verstuurt naar de client. De verbinding kan eventueel beveiligd worden door de verbinding over SSL te laten lopen. Dit is echter niet strikt noodzakelijk, omdat er al via VPN verbinding wordt gemaakt met de servers. Een andere mogelijkheid is om de communicatie te laten verlopen via de TenukiBus, die bij Hector v2 gebruikt gaat worden. Op deze manier kunnen we met behulp van een bus verbinding maken met de servers en er bijvoorbeeld XML-documenten over heen en weer sturen.

26

Voordelen: Gebruik van TCP (‘handshake’-mechanisme) We kunnen gebruik maken van bestaande Tenuki componenten Communicatie met server is hetzelfde voor Windows en Linux Nadelen: Twee verschillende server programma’s, daemon (Linux) en service (Windows)

VERGELIJKING In het begin leek het ons een goed idee om SNMP te gaan gebruiken. Dit omdat het toch wel redelijk de industriestandaard is voor monitoringtaken. Echter na gesprekken met Tenuki kregen we het idee dat ze toch liever geen SNMP wouden gebruiken. Daarom zijn we daar dus ook maar vanaf gestapt. Daar het monitoren nu over SSH en RDP gebeurt, was het een logische stap om te kijken of dit geautomatiseerd kon worden. Het bleek dat dit over SSH weldegelijk mogelijk is, maar dat RDP geen verbindingen zonder grafische omgeving toestaat. Hierdoor zou er een SSH server geïnstalleerd moeten worden op de Windows servers. Dit levert echter veel overhead, aangezien het voor een zeer kleine toepassing gebruikt zou gaan worden. Het protocol HTTP heeft veel voordelen wat betreft het cross-platform ontwikkelen. We kunnen ongeacht in welk OS we zitten, dezelfde gegevens oproepen met hetzelfde script. Om gebruik te kunnen maken van het HTTP protocol moet er echter wel een volledige webserver geïnstalleerd worden, omdat deze op vrijwel alle servers nog niet aanwezig is. Het schrijven van een eigen daemon heeft vele voordelen. Door het gebruik van TCP wordt er een verbinding opgezet waarbij we zeker weten dat onze pakketjes arriveren bij de server. Er is weinig tot geen overhead, aangezien een kleine daemon wacht op een aanroep van onze client. Voor het monitoringproces maken we alleen maar gebruik van een client-pull mechanisme. We willen op een bepaald moment de status van een server weten. Wanneer we constant een verbinding open laten en de server eventuele status veranderingen kan pushen, gaan we meer richting hetgeen Hector nu doet. Er zullen echter wel 2 verschillende daemons gemaakt moeten worden, aangezien we verschillende libraries nodig hebben voor Windows en Linux.

GEKOZEN PROTOCOL Uiteindelijk hebben we in overleg met de opdrachtgever gekozen om de communicatie te laten verlopen via een eigen daemon. Bij enkele lopende projecten wordt deze aanpak al gebruikt, waardoor er binnen het bedrijf dus ook al kennis van deze aanpak aanwezig is. Een ander groot voordeel is dat we gebruik kunnen maken van bestaande onderdelen uit de Tenuki library. Zowel het monitoringsysteem als het storingregistratiesysteem zullen deze vorm van communicatie gaan gebruiken. Dit heeft ook weer als voordeel dat de communicatie bij beide programma’s op dezelfde manier gedaan wordt, zodat we delen van onze programma’s kunnen hergebruiken. De communicatie verloopt nu dus als volgt. De clients hebben allemaal een client TCP socket en maken verbinding met de server TCP socket. Vervolgens verstuurt de client een in XML opgesteld verzoek naar de server, waarop de server in XML antwoordt geeft aan de client (client-pull).

27

MULTITIERARCHITECTUUR In het aantal gekozen tiers is er een verschil tussen het monitoringsysteem en het storingregistratiesysteem. Het monitoringsysteem maakt gebruik van een eenvoudige 2-tiersarchitectuur. Wat neerkomt op een clientserver relatie. De client is ook direct verbonden aan een database. Aangezien het niet waarschijnlijk is dat er overgestapt zal worden op een andere database leek het ons niet nodig om een extra tier hiervoor te maken. De storingsapplicatie maakt echter gebruik van een 3-tierarchitectuur. De presentatielaag bevindt zich bij de client, terwijl de businesslogic-laag en de datalaag op de server verblijven. Een request van de client gaat van de XMLClient naar de XMLServer aan de serverkant. Aan de hand van de inhoud van dit XML-document bepaalt de businesslaag wat de server gaat doen. In veel gevallen zal het een query naar de database uitvoeren. Het resultaat van deze query wordt omgezet in XML en teruggegeven aan de presentatielaag van de client.

5.3

DATABASEONTWERP

Hier gaan we in op het proces dat is doorlopen bij het database ontwerp. Er zal worden ingegaan op het functioneel ontwerp en het technische ontwerp. We bespreken de twee databasemodellen apart, aan de hand van de applicatie. Bij beide applicaties is een andere afweging gemaakt en zijn andere beslissingen genomen.

MONITORINGSYSTEEM Het databasemodel van het monitoringsysteem heeft een interessant proces doorlopen. Aan het begin van de ontwikkeling gingen we nog heel erg uit van het aangeleerde proces van het normaliseren. Normaliseren is fijn en het voorkomt redundante data. We hadden echter in het eerste ontwerp geen rekening gehouden met het feit dat het bijhouden van een geschiedenis van bepaalde gegevens wel meerwaarde heeft. In de loopt van het ontwerp proces is de normalisatie afgenomen en het bewaren van historische gegevens toegenomen in het ontwerp. In dit hoofdstuk bespreken we de stadia die we zijn doorlopen bij het ontwerpen van het database model en welke beslissingen er genomen zijn.

STAP 1 In de eerste fase hebben we een model gemaakt dat voldeed aan onze verwachtingen van een databasemodel. Dit databasemodel is een functioneel databasemodel dat weinig redundantie oplevert en de gegevens per controle benadert. Later kwamen we er achter dat dit ontwerp geen geschiedenis bijhoud, maar hierover later meer.

28

Figuur 10: Databasemodel fase 1 (configuratie links, opslag rechts)

We hadden twee modellen ontwikkeld: één voor het configuratie gedeelte en één voor de opslag van de monitoringresultaten. De database heeft voor elke controle een aparte tabel. De tabellen bevatten de nodige controles, die gekoppeld zitten aan een server. We merkten op dat de tabellen voor applicatiegeheugen, partitie, swap en inodes overeenkomstig zijn. Deze zouden we dus kunnen generaliseren tot de twee tabellen die ernaast weergegeven zijn: controle en type. Door alle namen te koppelen via id’s, wordt er veel ruimte bespaard en blijft de database een stuk kleiner. De controle van de afnemers week af van de andere controles. Dat is dan ook de reden dat we hier een andere tabel voor hebben geconstrueerd. De opslag van de monitoring gegevens werd een koppeling tussen de huidige tabellen. Een monitoring wordt gedaan op een bepaalde tijd en door een bepaalde medewerker. Deze monitoring zit gekoppeld aan servers, die weer gekoppeld zitten aan hun controles. Op deze manier dachten we weinig redundantie te creëren en alleen de nodige gegevens op te slaan.

CONCLUSIE STAP 1 Het model was overbodig complex. De generalisatie bleek een goeie oplossing, waarbij de afnemers er ook wel in mee konden worden genomen. Het grote voordeel van dit ontwerp is dat het erg functioneel is. Toevoeging van andere complexe ‘checks’ kan makkelijk met een eigen tabel. De redundante data die we op zouden kunnen slaan is echter niet dusdanig groot. Het opslaan van de gegevens was een heroverweging waard. Door het vermijden van redundantie verliezen we een stuk geschiedenis. Als we het ip-adres van een server namelijk halverwege de maand veranderen, staat er in het rapport het laatste ip-adres en niet het ip-adres van de monitoring op dat moment. Deze historie is dus zeer belangrijk voor een goede en kloppende rapportage. Een nieuwe versie van het database model was dan ook noodzakelijk.

STAP 2 In de tweede fase was het ontwerp al flink verkleind. De koppeling tussen configuratie en opslag is gemaakt en het aantal tabellen hebben we flink kunnen reduceren. 29

Figuur 11: Databasemodel fase 2 (configuratie links, opslag rechts)

Deze versie bevat de resultaten op een stuk overzichtelijkere manier. Dit ontwerp gaat veel meer richting het technische ontwerp. De controletabel bevat nu alle controles. Op deze manier wordt het een stuk overzichtelijker en minder complex. De koppeling tussen een controle en een resultaat van die controle is nu duidelijk weergegeven. Een monitoring bevat in deze versie simpelweg een aantal controles met bijbehorende resultaten.

CONCLUSIE STAP 2 Dit model benadert wat we uiteindelijk willen hebben. Het is een stuk overzichtelijker en de redundantie die meekomt is flink te overzien. Nieuwe ‘checks’ met een soortgelijke functionaliteit (naam, verbruik, min_threshold, max_threshold, prioriteit) zijn makkelijk toe te voegen. De gegevens van de servers worden nu nog steeds niet redundant opgeslagen. Hierdoor missen we dus geschiedenis van de servers (stel de servernaam veranderd halverwege de maand, veranderd hij overal (dus ook in het begin van de maand)).

STAP 3 Uit de derde fase kwam ons uiteindelijke technische ontwerp. De scheiding tussen configuratie en opslag is er nog steeds, maar zit niet meer gekoppeld. Op deze manier hebben we onze geschiedenis met een kleine hoeveelheid aan redundantie. Aan het server gedeelte en het controle gedeelte is weinig veranderd. De controles zijn simpel en overzichtelijk en de servertabel was al in orde. Na een monitoring hebben we nu twee verschillende resultaten, te weten: een serverresultaat en een controleresultaat. We slaan nu dus ook de resultaten van de server op die belangrijk zijn voor de rapportage. Een controleresultaat blijft zoals hij was. Veel van de configuratie verloopt via Delphi eenvoudig met behulp van .ini-files. We hebben in ons uiteindelijke programma alle configuratie ook lopen met behulp van de .ini-files. Daarom bevat de uiteindelijke database geen configuratietabellen. Deze tabellen kunnen bij een eventuele uitbreiding, waarbij wel gebruik gemaakt gaat worden van configuratie via de database, uitstekend gebruikt worden.

30

Figuur 12a: Model fase 3 met configuratie

Figuur 12b: Model fase 3 zonder configuratie

CONCLUSIE STAP 3 De database bevat redundante data, maar slechts voor controles en servers. Deze data was nodig voor de rapportages en moest dus wel degelijk terug te vinden zijn in de database. Het toevoegen van aparte controles die weinig gelijkenis vertonen met de huidige controles, zal gebeuren door nieuwe tabellen toe te voegen aan het huidige model. Dit doen we om te voorkomen dat er veel lege kolommen in de ControleResultaat tabel komen. De data die verwerkt moet worden in de database zal uiteindelijk niet teveel worden. Hiernaast zijn de rapportages ook een backup op papier en kunnen oude monitoringen verwijderd worden indien ze teveel ruimte innemen nadat ze gerapporteerd zijn. Gebruik van veel ruimte vond men bij Tenuki totaal geen probleem.

STORINGSREGISTRATIESYSTEEM Het database model voor de storingsrapportage is voornamelijk tot stand gekomen uit het bestuderen van de bestaande tekstbestanden waarin de storingen werden opgeslagen. In tegenstelling tot de monitoringapplicatie is er geen lang proces doorlopen. De hoeveelheid data en onderlinge relaties zijn namelijk miniem. Er zijn grofweg 2 stadia te onderscheiden. In stap 1 is er nog geen relatie tussen storingen en artikelen. In stap 2 is deze relatie er wel.

STAP 1 We hebben ons vanaf het begin geconcentreerd op puur de tabellen en velden die we na de analyse van de tekstbestanden dachten nodig te hebben voor de basisfunctionaliteit die in het rompsysteem verwerkt moest worden. Hier hebben we nooit ver naast gezeten en er is dan ook op hooguit een paar plaatsen een veld toegevoegd. Het model waarmee we begonnen zijn, is hieronder afgebeeld.

31

Figuur 13: Database model fase 1, storingsregistratie

STAP 2 In deze fase is de relatie tussen storingen en artikelen gelegd. Hiervoor is een extra tabel aangemaakt. Deze tabel zorgt voor de mogelijkheid van een n op n relatie van storingen en artikelen, zodat deze netjes aan elkaar gekoppeld kunnen worden.

Figuur 14: Database model fase 2, storingsregistratie

5.4

RAPPORTAGE

De monitoring en- storingsrapportage waren lange tijd gebaseerd op XML in combinatie met XSLT, xHTML en CSS. De gegevens worden uit de database gehaald, omgezet in XML met een XML-convertor en deze XML-code wordt weggeschreven in een bestand en opgeslagen op de computer van de gebruiker. Aan dit xml-bestand wordt een xslt-bestand gekoppeld welke de transformatie van XML naar xHTML regelt. Voor de opmaak van het xHTML-bestand wordt CSS gebruikt. 32

Uit verschillende gesprekken en gebruikers sessies is uiteindelijk gebleken dat het wenselijk is om de uitvoer van de storingsrapportages nog enigszins aan te kunnen passen. Een xHTML bestand is daarvoor onvoldoende gebruikersvriendelijk en daarom is besloten om de storingen in Rich Text Format weg te schrijven, zodat ze later eventueel met een tekstverwerkingsprogramma bewerkt kunnen worden. De gegevens worden in dit geval uit de database gehaald, en in plaats van naar XML, direct naar RTF geschreven. Er had ook gekozen kunnen worden voor een XML naar RTF conversie, maar deze transformatie vergt, in tegenstelling tot de transformatie naar xHTML, een XSLT-processor. Dit houdt in dat in het gemakkelijke geval op de client-computer een dergelijke parser geïnstalleerd moet staan. Dit is echter niet wenselijk. Een tweede en laatste optie is om een parser op de server-side te installeren, maar dit zou ons te veel tijd kosten. Mede doordat de XSLT een stuk lastiger wordt dan bij de transformatie naar xHTML. Ook hebben we uitgezocht of we XML naar WordML, het xml-formaat van Microsoft, konden transformeren. Voor deze transformatie zou er wederom een parser geïnstalleerd moeten worden. Bovendien wordt het WordML-formaat alleen in versies van Office 2003 en hoger goed ondersteund. Aangezien er binnen Tenuki met de 2001 versies wordt gewerkt viel deze optie dus al snel af. Voor de uitvoer van de monitoringraportage zijn bewerkingen achteraf uitgesloten en derhalve is er hier voor gekozen de aanpak van XML, XSLT, xHTML en CSS door te zetten.

5.5

HET OBSERVER DESIGN PATTERN

Het Observer design pattern wordt gebruikt om objecten binnen een programma te wijzen op toestandsveranderingen van andere objecten. Dit wordt gedaan d.m.v. Observers en Subjects. Het Subject is het object waarvan de toestand in de gaten gehouden wordt door de Observer. De Observer kijkt niet steeds of het Subject al veranderd is, maar het Subject kan de toestandsverandering publiceren aan luisterende Observer objecten. De Observer objecten kunnen actie ondernemen nadat een Subject hen gewaarschuwd heeft voor een toestandsverandering. Het doel van het Observer design pattern is dat toestandsveranderingen opgemerkt worden door andere objecten. Dit kan handig zijn als een object tegelijkertijd verschillende representaties kan hebben. Denk bijvoorbeeld aan een spreadsheet programma met een aantal waarden en een grafiek die de waarden visualiseert. Als een waarde in een cel verandert, moet de grafiek meeveranderen. In dit geval is de cel het Subject en de grafiek de Observer, want de grafiek reageert op een verandering van het subject. We hebben het Observer design pattern gebruikt, omdat het ons een goede oplossing leek voor het weergeven van de storingen in de storingsadministratie applicatie. Uiteindelijk hebben we er maar weinig profijt van gehad. We gebruiken het als volgt. Het Subject is een storing. Als een nieuwe of een reeds bestaande storing opgeslagen wordt, krijgen de Observer objecten een bericht dat de storing veranderd is. Deze Observer objecten zullen dan bepaalde acties uitvoeren, zoals het verzenden van de storing, vertaalt naar XML, naar de server. Hier hadden we het Observer design pattern niet voor nodig. Daarom hebben wij een zogenaamde kennisbank voorgesteld. In deze databank worden artikelen gezet die op een gedetailleerde wijze uitleggen hoe een bepaald probleem opgelost kan worden. De zoekmachine moet helpen in het vinden van relevante storingen en artikelen. Een ander plan was, maar alleen bij tijd over, om een koppeling te maken tussen de storingen en artikelen. Het ‘hoe’ van dit laatst genoemde was in het begin nog niet uitgewerkt. Voor de administratieve medewerker hadden we een goed, helder overzichtsscherm voor ogen. Hierin zouden de kerntaken voor de administratieve taken, met als belangrijkste het rapporteren, verweven liggen. Door middel van het selecteren van storingen uit het overzicht zou er een document geëxporteerd kunnen worden. 33

6.

REALISATIEPROCES

In dit hoofdstuk behandelen we de verschillende iteraties in fasen die we doorlopen hebben. Zoals ook in hoofdstuk 2 te lezen is, verliep elke iteratie min of meer hetzelfde. We begonnen elke fase met een analysefase, waarin bepaald ging worden wat er diende te gebeuren in de desbetreffende iteratie. Ook bepaalden we welke onderdelen aan het einde van de iteratie af waren. Vervolgens gingen we deze onderdelen implementeren. Ten slotte lieten we de resultaten van de iteratie zien aan de gebruiker en overlegden we over het systeem. Deze zaken werden verwerkt in de volgende iteratie, zodat we dezelfde cirkel opnieuw in gingen. We zullen deze stap voor stap behandelen.

6.1

ITERATIE 1: ROMPSYSTEEM

Dit is de allereerste versie van het systeem waarin alleen de kernfunctionaliteit is verweven. In deze fase is ook het begrijpen van de eXtreme Programming methodiek zeer aanwezig geweest. Het begrijpen van de Tenuki werkwijze was hier zeer mee verworven en is belangrijk geweest voor het verdere verloop van het project.

6.1.1 REQUIREMENTS (WAT) In deze paragraaf behandelen we de requirements die we verkregen hebben in de eerste iteratie van ons realisatieproces. A Beide programma’s: 1. 2. 3.

Communicatie: client-server model met behulp van berichten via xml Ontwikkeling GUI voor rompsysteem en uiteindelijke versie (hoe komt GUI eruit te zien) Ontwikkeling van het databasemodel

B Storingsregistratie: 4. 5.

Communicatie met de database: laten verlopen via 3-tiers Creëren/tonen/bewerken/verwijderen storingsregistraties

C Monitoringsysteem: 6. 7. 8.

Communicatie met de database: direct via clientapplicatie Ruimtegebruik partities en processor load monitoren van één server Eenvoudige rapportage aan de hand van XML

De onderverdeling van de onderdelen zijn aangegeven via de nummering. Elke onderdeel start met een letter gevolgd door een cijfer. Als we het hebben over A3, betekent dit dat we spreken over de ontwikkeling van het databasemodel. Belangrijke en nog onbehandelde onderdelen lichten we er in deze paragraaf uit. A1: De communicatie is een belangrijk punt, aangezien de desktopapplicaties gebruikt gaan worden door verschillende medewerkers en de communicatie synchroon moet blijven verlopen. Een centraal gelegen database was dan ook een keuze die al vroeg gemaakt kon worden. Voor het monitoringsysteem konden verschillende methoden gekozen worden om de communicatie mee te laten verlopen. Uiteindelijk hebben we (zoals ook te lezen is in hoofdstuk 5) gekozen voor TCP met behulp van berichten over XML.

34

A2: Het tekenen van GUI’s op papier is een belangrijk aspect binnen Tenuki. Op deze manier kunnen de gebruikers al in een vroeg stadium een beeld vormen van de daadwerkelijke vorm van de applicatie. Hierdoor kan er vroeg meegedacht worden en kunnen verkeerde gedachtes al vroeg verholpen worden. Ook wij hebben tekeningen gemaakt van onze beoogde uiteindelijke GUI’s en van de GUI’s aan het einde van de eerste iteratie:

Figuur 15: GUI Rompsysteem, monitoring

Figuur 16: Overzichtsscherm storingen

35

Figuur 17: Storing toevoegen

B4: Zoals in A1 al geschreven is, was het een logische keuze om de database op de server te plaatsen zodat alle gegevens over storingen centraal opgeslagen kunnen worden. Het leek ons echter ook een goed idee om tussen de database tier nog een ‘Business Logic’ tier toe te voegen. In deze tier kunnen we logica loslaten op de data die van en naar de server gestuurd wordt. De client en logic tiers communiceren door middel van XML over het TCP protocol. Achteraf bleek deze stap overbodig. De hoeveelheid logica die we toepasten op het dataverkeer was minimaal te noemen, terwijl het veel werk was om daadwerkelijk met de database te communiceren. Achteraf gezien hadden we misschien beter direct vanuit de client applicatie met de database kunnen communiceren. Als we die keuze hadden gemaakt was de architectuur een stuk beter uitbreidbaar en minder complex. Aan de andere kant, we kozen ervoor omdat we het een uitdaging vonden om de 3-tier architectuur te implementeren. B5: Een van de basisfuncties van de applicatie is het aanmaken, wijzigen, verwijderen en bekijken van storingen. Deze functionaliteit hebben we direct geïmplementeerd nadat de communicatie tussen de drie tiers mogelijk was. Nu we met de client applicatie wat taken uit konden voeren, hadden we ook iets om over te discussiëren met de gebruikers. C2: De belangrijkste functies om te monitoren, zijn de grootte en het bezette percentage van de verschillende partities. Ook willen we de load van de CPU gaan monitoren. Deze twee onderdelen worden als eerste geïmplementeerd en meegenomen in het rompsysteem omdat we werken volgens het paradigma: de belangrijkste zaken eerst. C3: Om een beeld te vormen van de totale applicatie en om alle onderdelen in de breedte mee te nemen in het rompsysteem, ontwikkelen we in deze fase ook een eenvoudige rapportage, aan de hand van XML.

36

6.1.2 RESULTATEN In deze paragraaf behandelen we per systeem de resultaten die we behaald hebben in de desbetreffende fase. Het opzetten van een planning was een belangrijke vereiste van onze begeleider dhr. Kluit. Ook zelf wilden wij duidelijk hebben wat we gingen doen en welke tijdspan we daarvoor wilden benutten. Tijdens het opzetten van de planning wilden we direct alle mogelijke requirements verkrijgen en direct op papier zetten wat we over 8 weken bereikt wilden hebben. Een remming van de kant van Tenuki bleek nodig, aangezien we dit helemaal niet moesten willen. Het kostte ons dan ook de nodige moeite om een planning op te zetten. Slechts een aantal weken vooruit wisten we wat we moesten doen. Later bleek dit een stuk eenvoudiger om te begrijpen en om ermee te werken. Extreme Programming heeft als één van de belangrijkste onderdelen: het werken in prioriteiten. Belangrijkste zaken dienen als eerste aangepakt te worden. Voor de eerste fase bleken dit de volgende zaken te zijn:

MONITORINGSYSTEEM De resultaten aan de hand van de functionaliteit van het rompsysteem hebben we op papier gezet. We zullen beginnen met een lijst met schermen die gemaakt zijn aan het einde van de eerste fase. Hierna zullen we per punt kort toelichten welke acties door de gebruiker uit te voeren zijn en welke resultaten hij/zij ziet op het scherm. Hoofdscherm Monitoringscherm Overzichtscherm Rapportagescherm

HOOFDSCHERM In dit scherm is een server te zien die op een aantal punten gemonitord kan worden. Verder is er een knop waarmee de monitoring gestart kan worden. In de eerste fase is er één systeem (een distributieserver) dat gemonitord kan worden.

MONITORINGSCHERM Op dit scherm worden de naam en het type van de server getoond wordt. Verder kan voor opgegeven (hardcoded) partities de vrije ruimte worden weer gegeven. Wanneer deze buiten een vast gestelde thresholdwaarde (ook hard-coded) valt, kan er een melding worden getoond, dat de gebruiker moet opletten bij dat onderdeel. Verder kan er een overzicht worden getoond van het CPU gebruik. Ook is er een knop die gebruikt kan worden om naar het overzicht van alle gemonitorde servers te gaan.

OVERZICHTSCHERM Op het overzichtscherm wordt getoond hoe laat en wanneer de monitoring is voltooid en welke server is gemonitord.

37

RAPPORTAGESCHERM Op het rapportagescherm kan de gebruiker kiezen van welke monitoringen er een rapport moet worden gemaakt. Hier kunnen de gebruikers op een knop drukken, waarna een rapportage van de desbetreffende monitoring kan worden opgeslagen. Het resultaat wordt opgeslagen in een tekstdocument in een leesbaar formaat. N.B. Er moet hier wel opgemerkt worden dat er in deze fase slechts gebruik gemaakt wordt van één enkele server. In een volgende fase zal er functionaliteit worden toegevoegd om meerdere servers te monitoren.

STORINGREGISTRATIESYSTEEM We starten twee executables (client, business logic) en de database. De business logic draait in dit geval op de client-computer naast het client programma en dient handmatig gestart te worden. In deze fase draait er dus nog geen service op een externe server. Via de client executable wordt in eerste instantie het overzichtsscherm getoond. Hier zijn de storingen van de huidige maand in een lijst. Het is mogelijk om een periode aan te geven van storingen die worden getoond.

OVERZICHTSCHERM Van hieruit kan er gekozen worden om een nieuwe storing toe te voegen. Deze kan worden opgeslagen in de database en verschijnt vervolgens ook in het overzicht. In het overzicht kan een storing geselecteerd worden die met een druk op de knop "geëxporteerd" wordt als xml-bestand. Je hebt nu de mogelijkheid om het bestand op de harde schijf van de client op te slaan.

KENNISBANK De kennisbank kan nog niet gevuld worden met artikelen. De schermen zijn al wat gereed, maar de logica erachter (welke inprincipe voor een groot deel overeenkomt met die van de storingen) werkt nog niet.

ZOEKEN De zoekfunctie in deze iteratie heeft zich beperkt tot het in het overzichtscherm sorteren op datum en is dus nog heel basaal. Er is nog geen apart scherm uitgewerkt voor de echte zoekopdrachten waarbij op meerdere velden gezocht kan worden.

6.2

ITERATIE 2: BETA VERSIE

Nu de eerste iteratie achter de rug is kan het systeem verder uitgebreid gaan worden. Een groot deel van de belangrijke functionaliteit is reeds aanwezig en de eerste feedback van de gebruikers en opdrachtgever is ontvangen. Deze feedback zullen we dus ook in deze versie verwerken. Het doel is dat deze versie de uiteindelijke versie functioneel gezien benadert, zodat in de laatste iteratie voornamelijk nog cosmetische aanpassingen gedaan moeten worden.

38

6.2.1 REQUIREMENTS (WAT) Ook aan het begin van deze iteratie wordt er gekeken wat precies het doel is van deze iteratie. Er wordt op papier gezet wat er precies gedaan moet worden en dit wordt overlegd met de opdrachtgever. Voor iteratie twee zijn we op de volgende dingen uitgekomen. A Beide programma’s: 1. 2. 3.

INI configuratiefiles Database Schalende UI

B Storingsregistratie: 1. 2. 3.

Kennisbank Zoeken Toolbar

C Monitoringsysteem: 1. 2. 3. 4. 5.

Meerdere servers monitoren Formaat rapport vastleggen Linux daemon Rapportagescherm Controles

We zullen hier wat meer uitleg geven over de hierboven genoemde punten. Dit gebeurd op dezelfde manier als bij de eerste fase.

A1: INI CONFIGURATIEFILES Belangrijke instellingen aan de client- en serverapplicaties die niet van binnen de applicatie zelf aangepast hoeven te worden, bijvoorbeeld omdat dit zelden nodig is, maar niet hard-coded opgenomen mogen worden, hebben we variabel gemaakt door middel van .ini-bestanden. Door gebruik te maken van de bestaande TenukiConfig en TenukiSettings componenten zijn verschillende instellingen aan te passen. Voor het monitoringsysteem gaat het dan op te slaan welke servers er gemonitord moeten worden aan de client zijde. We specificeren hier het ip-adres van de server en de poort waar ons server proces op luistert. Aan de server zijde is er een configuratiebestand waar in staat welke controles er voor die specifieke server uitgevoerd moeten worden. Verder is er ook nog een configuratiebestand voor het rapportageprogramma. Hierin staat vermeldt welke server en welke controles voor deze server in de uiteindelijk rapportage terecht moeten komen. Voor het storingsregistratiesysteem is op de serverside configuratie een lijst van medewerkers, een lijst van systemen, een lijst van mensen die vaak storingen melden en een start datum voor de rapportageperiode opgenomen in het configuratiebestand. Ook kunnen de gegevens van de database worden ingesteld. Aan de clientside wordt via het configuratiebestand ingesteld wat de naam is van de gebruiker van de applicatie. Hierdoor worden bepaalde velden in het registratieformulier alvast ingevuld. Bovendien moet opgegeven worden wat het ip-adres naar de service is en naar welke port deze luistert.

39

A2: DATABASE Aan het eind van fase 1 hebben we ervoor gekozen om de data maar als platte XML op te slaan in de database. Dit is natuurlijk niet de bedoeling voor het uiteindelijke product. Daarom gaan we in deze fase de echte database backend implementeren. Er zullen een aantal tabellen worden aangemaakt waar we de data in op kunnen gaan slaan. Het database-model voor de storingsregistratie hoeft niet veranderd te worden, omdat er al voorbereid was op de kennisbankartikelen die we in deze fase verder zullen implementeren.

A3: SCHALENDE UI In fase 1 hadden we nog geen aandacht besteed aan het laten schalen van de applicatie. Dit was ook nog niet echt heel nodig, maar het is natuurlijk wel mooi als dit wel gedaan kan gaan worden. Daarom gaan we in fase 2 de applicatie laten meeschalen. Tijdens de eerste presentatie aan het einde van de eerste iteratie liepen we tegen een aantal problemen aan toen we de applicatie draaide op een scherm met een te lage resolutie. De storingsadministratie applicatie paste niet op het scherm, waardoor we slechts enkele functies konden laten zien aan de aanwezige gebruikers en opdrachtgevers. Erg jammer, omdat we er erg hard aan gewerkt hadden. Het had dus een hoge prioriteit om de applicatie te draaien op verschillende resoluties.

B2: KENNISBANK De kennisbank kan worden aangevuld met items. Deze worden opgeslagen in de database. Daarnaast kan er door de items van de kennisbank gebladerd worden. Dit zal in de vorm zijn van een overzichtsscherm.

B3: ZOEKEN De zoekfunctie voor rapportages en kennisbank items staan samen op een scherm. Er zit nog geen ratingsysteem achter of enige vorm van intelligentie. Er zal simpelweg gezocht worden op overeenkomende velden in de database. Er is een veld dat ingevuld kan worden en dit veld proberen we te matchen tegenover alle velden in de database. Het resultaatscherm is het overzichtsscherm, maar dan met de zoekresultaten. Dit resultaatscherm wordt gesplitst in twee delen. Voor elke tabel (storingen/kennisbank) een eigen overzicht.

B4: TOOLBAR Om het gebruikersproces te ondersteunen (een toolbar is immers, mits goed uitgewerkt, een heldere en snelle manier om tot actie over te gaan) willen we in deze iteratie een toolbar implementeren. Deze komt zoals gebruikelijk is, bovenaan te staan en is voorzien van sprekende icoontjes.

C1: MEERDERE SERVERS MONITOREN In fase 1 hebben we ervoor gekozen om het zo eenvoudig mogelijk te houden. We wouden toen een aantal eigenschappen van een server kunnen monitoren. Voor het monitoren is echter nog een iteratief proces nodig. In deze fase zullen we het dus mogelijk gaan maken om meerdere servers te kunnen monitoren.

40

C2: FORMAAT RAPPORT VASTLEGGEN In de eerste fase hebben we de gemonitorde gegevens in een XML bestand gezet. Dit XML bestand hebben we heel eenvoudig met XSLT opgemaakt. Voor de eerste fase was dit voldoende voor het rapport. De opmaak is echter bijzonder eenvoudig. We zullen in de fase de opmaak van het rapport grondig onder handen gaan nemen, zodat het er goed genoeg uit ziet om naar de klanten te sturen.

C3: LINUX DAEMON In fase 1 hebben alleen nog maar ontwikkeld voor het Windows platform. Een groot deel van de code kan rechtstreeks gebruikt worden met de Linux versies. Echter zullen de controles apart geïmplementeerd moeten worden voor het Linux platform. Aangezien het merendeel van de servers op Linux draait is dit een hele relevante uitbreiding.

C4: RAPPORTAGESCHERM Op het rapportagescherm kan de gebruiker kiezen van welke monitoringen er een rapport moet worden gemaakt. Hier kunnen de gebruikers verschillende monitoringen aanvinken en zichtbaar maken in de rapportage. De monitoringen zijn geordend per vier weken. Met een druk op de knop 'opslaan' wordt het monitoringsrapport opgemaakt en weggeschreven op een zelf te kiezen locatie.

C5: CONTROLES In de eerste fase was het nog niet mogelijk om echt controles uit te voeren op de gemonitorde gegevens. In fase twee zullen we dit wel gaan implementeren. De applicatie krijgt nu enige intelligentie en zal waarschuwingen gaan geven als het resultaat van een controle boven of onder een vast gestelde grens uitkomt.

6.2.2RESULTATEN In deze paragraaf behandelen we per systeem de resultaten die we behaald hebben in de desbetreffende fase.

MONITORINGSYSTEEM In de tweede fase is het monitoringsysteem hard vooruit gegaan. Het toevoegen van meerdere servers gebeurde vlug doordat we steeds beter wegwijs raakten met Delphi. We bespreken opnieuw de schermen en de resultaten die we geboekt hebben. We zullen beginnen met een lijst met schermen die gemaakt zijn aan het einde van de tweede fase. Hoofdscherm Monitoringscherm Overzichtscherm Rapportagescherm

41

HOOFDSCHERM In dit scherm zijn een of meerdere servers te zien die op een aantal punten gemonitord kunnen worden. Het hoe of wat van wat er gemonitord kan worden staat in een .ini file op de server. Welke servers er gemonitord kunnen worden, staat in een .ini file op de client. Verder is er een knop waarmee de monitoring gestart kan worden. De gebruiker kan zelf één of meerdere servers aanvinken die meegenomen moeten worden in de monitoring.

OVERZICHTSCHERM Op het overzichtscherm wordt getoond hoe laat en wanneer de monitoring is voltooid en welke servers zijn gemonitord. Op het overzichtscherm kan direct gezien worden welke servers 'succesvol' en welke 'onsuccesvol' gemonitord zijn. Dit gebeurt aan de hand van het icoontje voor de naam van de server. Achter de naam van een 'onsuccesvolle' server is ook direct één (van de eventueel meerdere) waarschuwingen te zien.

MONITORINGSCHERM Op dit scherm worden de naam en het type van de server getoond. Op dit scherm zijn alle gemonitorde resultaten weergegeven. Welke onderdelen van een server gemonitord zijn, bevindt zich in een .ini file op de desbetreffende server. Elk onderdeel staat in een apart tabblad. Bovenaan in een tabblad staat/staan de eventuele waarschuwing(en). Hieronder staan de resultaten van de monitoring voor het onderdeel van het desbetreffende tabblad. Als een server waarschuwingen bevat, is het tabblad oranje gekleurd. Bevat het geen waarschuwingen, is de kleur hetzelfde als de achtergrond. Het monitoringscherm heeft (mochten er waarschuwingen zijn) altijd het tabblad met de waarschuwing als eerste geopend. Op deze manier kan de gebruiker direct zien wat er op te merken valt op de server.

.INI-FILES Op de servers komt (zoals eerder verteld) een .ini file te staan. In deze file staan de monitoren functies per server. De gebruiker kan deze .ini files aanpassen om zo de monitoring te veranderen. Aan het einde van de tweede fase willen het volgende monitoren voor Windows- en Linuxservers: Geheugengebruik per applicatie CPU-load Vrij werkgeheugen Vrije harde schijfruimte per partitie Vrije inodes per partitie (linux) Afnemers (distributieservers)

RAPPORTAGESCHERM Op het rapportagescherm kan de gebruiker kiezen van welke monitoringen er een rapport moet worden gemaakt. Hier kunnen de gebruikers verschillende monitoringen aanvinken en zichtbaar maken in de rapportage. De monitoringen zijn geordend per vier weken. Met een druk op de knop 'opslaan' wordt het monitoringrapport opgemaakt en weggeschreven op een zelf te kiezen locatie.

42

STORINGREGISTRATIESYSTEEM De onderdelen uit het storingsregistratiesysteem die aan de orde zijn gekomen worden in deze fase stuk voor stuk geëvalueerd.

SCHALENDE UI Alle schermen van de applicatie zijn onder handen genomen. Het storingsregistratieformulier schaalt, evenals het artikelenformulier correct mee. Het hoofdformulier en de schermen die via de tabs te benaderen zijn werken allemaal zoals we dat voor ogen hadden.

KENNISBANK Doordat in de vorige iteratie de kennisbank nog niet was geïmplementeerd, moest er in deze iteratie een inhaalslag gemaakt worden. Dat is gelukt en alle functionaliteit werkt naar behoren.

ZOEKEN De zoekfunctionaliteit is naar behoren uitgebreid. Er is nu een aparte tab waarop twee zoekformulieren zijn geplaatst. Links voor het zoeken naar storingen, rechts voor het zoeken naar artikelen. De zoekresultaten verschijnen in de overzichtsschermen van respectievelijk de storingen en artikelen. Op de volgende velden is te zoeken: Storingen kunnen gezocht worden op: Naam Gemeld door Gemeld via Behandeld door Probleem Meldingsdatum Kennisbank items kunnen gezocht worden op: Naam Auteur Tekst Tags

TOOLBAR Er is een toolbar beschikbaar die de volgende functionaliteit biedt: Nieuwe storingen registreren Nieuw kennisbankartikel aanmaken Geselecteerd item bewerken Geselecteerde items verwijderen Exporteren

43

Voor al de opties is een icon die de actie representeert. Tevens is van elke icon een grijswaarde duplicaat gemaakt welke te zien is wanneer een optie niet beschikbaar is.

6.3

ITERATIE 3: RELEASE KANDIDAAT

De release kandidaat is een uiteindelijke versie met alle benodigde functionaliteit. Ook in deze iteratie is er een analyse gemaakt van waarop gefocust moet worden.

6.3.1 REQUIREMENTS (WAT) A Algemeen: 1. 2.

Verslag Servers laten draaien als respectievelijk services en daemons

B Storingsregistratie: 1. 2.

Koppeling kennisbank Gebruiksvriendelijke UI

C Monitoringsysteem: 1. 2.

Rapportage afgerond en configureerbaar Connectiviteit afnemers, inodes en .ADY-files monitoren

A1: VERSLAG Het verslag was tot nu toe slechts een ongebundelde verzameling van allerlei documenten die wij gedurende de andere iteraties hebben bijgehouden. Wel hadden we een opzet bedacht voor ons verslag en deze laten goedkeuren. In deze iteratie moest er een begin gemaakt worden met het invullen van onze opzet.

A2: SERVERS LATEN DRAAIEN ALS RESPECTIEVELIJK SERVICES EN DAEMONS De serverside applicaties draaiden vooralsnog steeds op de client computers als simpele executables. De stap naar een Windows Service en een Linux Daemon moet in deze iteratie gemaakt worden.

B1: KOPPELING KENNISBANK De opzichzelfstaande storingen en artikelen moeten in deze iteratie op de een of andere manier aan elkaar gekoppeld worden. Naar aanleiding van verschillende gesprekken hebben we besloten om een drag ’n drop functionaliteit toe te voegen. Op deze manier is het straks heel intuïtief om artikelen letterlijk naar storingen te slepen en de twee op deze manier te koppelen. Een andere mogelijkheid was geweest om gebruik te maken van dropdown boxes. Er zou dan bijvoorbeeld gekeken kunnen worden welke vensters actief zijn om deze vervolgens op te nemen in de box. Het idee van het slepen en vooral het gebruikersgemak hiervan sprak ons, en Tenuki, echter meer aan.

44

B2: GEBRUIKSVRIENDELIJKE UI Er zijn nog een aantal punten in de user interface, onder andere qua naamgeving, die verbeterd kunnen worden. Wij zullen in deze iteratie samen met de grafisch ontwerpster van Tenuki een blik werpen op de applicatie.

C1: RAPPORTAGE AFGEROND EN CONFIGUREERBAAR De rapportage diende configureerbaar te worden. Aangezien de pagina’s geen eeuwige breedte hebben, moest de gebruiker een keuze kunnen maken tussen de verschillende checks en welke hij/zij in de rapportage op willen nemen.

C2: CONNECTIVITEIT AFNEMERS, INODES, EN .ADY-FILES MONITOREN Er zijn drie checks toegevoegd in deze fase, te weten: connectiviteit afnemers (geeft aan hoeveel afnemers verbonden zijn met een server), de totale en beschikbare inodes (gebeurt alleen op Linux servers) en het checken van .ady-files. Deze laatste files bevatten informatie die nodig is voor de fileinformatie. Ons systeem checks hun aanwezigheid en geeft een timestamp terug. Het is aan de gebruiker om aan te geven of de timestamp al dan niet correct is.

6.3.2 RESULTATEN In deze paragraaf behandelen we per systeem de resultaten die we behaald hebben in de desbetreffende fase.

MONITORING In deze laatste fase moesten echt de puntjes op de spreekwoordelijk i worden gezet. Zo zijn we verder gegaan met de service en daemon, hebben we de laatste hand gelegd aan de rapportage en hebben we de laatste paar benodigde controles toegevoegd.

SERVICES EN DAEMONS In de derde fase zijn we het server programma klaar gaan maken voor productie. De laatste paar dingen moesten nog voor Linux gemaakt worden. Na wat tijd is dit echter goed voor elkaar gekomen. Toen we echter onze versie wilde uitrollen naar de server, liepen we tegen een raar probleem aan. Op ongeveer 80% van de servers wilde de applicatie niet draaien. Na meer dan een dag zoeken bleek dat de bewuste server allemaal op kernel versie 2.4 draaien. Ons programma werkte echter alleen op 2.6 kernels. We moesten dus een manier gaan vinden om ook een versie te maken die geschikt was voor 2.4 kernels. Weer een goede dag later hebben we dit voor elkaar gekregen door het gebruik van andere, Linux componenten van Tenuki. Deze componenten hadden ze niet echt meer in gebruik en waren vervangen door het component wat we in eerste instantie gebruikte. Deze werkte echter zoals gezegd niet met kernel 2.4 en het was dan ook de redding van ons project dat deze componenten nog beschikbaar waren. Toen dit eenmaal gemaakt was, zijn we verder geen noemenswaardige problemen meer tegen gekomen.

45

RAPPORTAGE AFGEROND De rapportage is misschien wel het belangrijkste argument om de monitoring te automatiseren. We kwamen er echter in fase 2 achter dat we daar iets te weinig aandacht aan hadden besteed. Het ontwerp moest overhoop gegooid worden en er moest een hele nieuwe applicatie gemaakt worden om de rapportages mee te genereren. Na een dag hard werken was deze applicatie, ter grote verbazing van onszelf, grotendeels ook af. Aan het eind van fase 3 was deze dan ook helemaal af.

AFNEMERS, INODES EN .ADY-FILES MONITOREN Ook zouden we in deze laatste fase de laatste controles toevoegen. Dit is zonder noemenswaardige problemen ook goed gelukt.

STORINGSREGISTRATIE De stappen die in de derde iteratie zijn gemaakt, te weten het koppelen van kennisbankartikelen aan storingen en het verbeteren van de gebruiksvriendelijkheid van de grafische userinterface worden in deze paragraaf geëvalueerd.

KOPPELING KENNISBANK De artikelen en storingen zijn nu door middel van drag and drop te koppelen. In het artikelscherm is een plaatje van een brein opgenomen. In het storingsregistratieformulier is een droparea gedefinieerd. Door het breinfiguur als het ware te verslepen naar de droparea worden het artikel en de storing gekoppeld. Het is ook mogelijk om gemaakte koppelingen te verbreken. De koppeling wordt bovendien verbroken zodra of de gekoppelde storing of het gekoppelde artikel zelf verwijderd wordt.

GEBRUIKSVRIENDELIJKE UI Het is belangrijk dat de omschakeling van kladblok naar storingsregistratie venster zo soepel mogelijk verloopt. Door enkele gebruikers een storing in te laten voeren in het nieuwe systeem, kwamen zaken aan het licht die voor de gebruikers nog niet volledig duidelijk waren. We kwamen er bijvoorbeeld achter dat de volgorde van de invoer velden niet helemaal overeenkwam met de volgorde die de gebruikers gewend waren. Daarnaast was het niet precies duidelijk wat in ieder veld ingevoerd moest worden. We hebben daarom de positionering en de naamgeving van enkele velden aangepast. Daarnaast hebben we ‘tooltips’ toegevoegd aan de invoervelden. Deze tooltips geven de gebruiker inzicht over wat er precies in het veld ingevoerd dient te worden.

46

7.

BEHAALDE DOELSTELLING

Dit hoofdstuk beschrijft in hoeverre we de gestelde doelstellingen hebben gehaald. Waarbij de algemene doelstelling is dat de gebruiker in zijn werk ondersteund wordt. We zullen beide systemen apart behandelen.

7.1

MONITORING

De huidige monitoring gebeurde, zoals eerder vermeld, voornamelijk handmatig. Het monitoring programma gaf een tekstuele output terug die gekopieerd werd in kladblok. Vervolgens werden handmatig de resultaten vergeleken met de vorige monitoring en werd het aan het einde van de maand handmatig in een Word document gezet om van daaruit de rapportage op te stellen. We onderscheiden twee gebruikersgroepen, te weten: de mensen die monitoren en de mensen die rapportages opstellen. In dit hoofdstuk vermelden we in hoe verre en op welke manier we het gebruikersproces ondersteunen.

MONITOREND PERSONEEL Het belangrijkste voor de mensen die monitoren is dat ze geen belangrijke verschillen ten opzichte van een vorige monitoring zien. Het handmatige hierin hebben we kunnen automatiseren met behulp van de thresholds. De thresholds worden eenmalig ingesteld en zorgen ervoor dat het systeem automatisch weergeeft of een waarde zijn threshold gepasseerd is. De waarden van de vorige monitoring zijn weergegeven naast de waarden van de huidige monitoring. Op deze manier kunnen de gebruikers monitoren op de manier waarop zij dit gewend waren. Zo hoeven ze geen nieuw proces aan te leren. Het monitoren werkt tevens intuïtief, waardoor ook nieuwe werknemers eenvoudig kunnen beginnen met monitoren en zodoende deze taak overnemen van andere werknemers. Er is ook een grote tijdswinst geboekt ten opzichte van de oude monitoring. Bij de oude monitoring moest met elke server handmatig verbinding gemaakt worden. Met de nieuwe versie is dit niet meer nodig. Door de daemons die draaien op de servers, kan het programma direct verbinding maken met de desbetreffende servers. Op deze manier worden resultaten sneller verkregen en kunnen er eventueel meerdere monitoringen op een dag uitgevoerd worden.

RAPPORTEREND PERSONEEL Bij het rapporteren is een hoop verandering bewerkstelligd. Waar de gebruikers eerst alle data met behulp van een kladblok moesten kopiëren in een Word document, is een enkele druk op de knop nu voldoende. De data van de monitoringen staan allemaal opgeslagen in de database en kunnen er voor rapportages uitgehaald worden. Het enige dat hoeft te gebeuren is een selectie van de periode waarvan de rapportage opgesteld moet worden (deze staat standaard al ingesteld op de meest waarschijnlijke periode), waarna de rapportage automatisch gegenereerd wordt. Alle opmaak wordt gedaan en het rapport is direct af te drukken. Een enorme winst dus. Tevens heeft het rapportagedeel een nieuwe toevoeging ten opzichte van de oude rapportages. Het programma rekent namelijk de gemiddelde waarden van de monitoringresultaten uit en gebruikt deze in de rapportage.

7.2

STORINGSREGISTRATIE

De drie verschillende gebruikersgroepen (experts, leerlingen, administratie) die we hebben onderscheiden, hebben allen hun eigen ondersteuning nodig. Er wordt kort samengevat wat deze ondersteuning inhoudt en in hoeverre we dit hebben bereikt. 47

EXPERTS De focus voor de experts, degene die op dit moment goed weten hoe storingen moeten worden verholpen en geregistreerd, heeft altijd gelegen op het snel kunnen registreren van een nieuwe storing. De overstap van het via notepad invullen van een storing naar het invullen via een formulier in de applicatie moest niet te groot worden. In de basis is het registreren van storingen daarom hetzelfde gebleven. De volgorde van ‘velden’ in notepad is overgenomen voor het formulier in de applicatie. Door middel van tabtoetsen, die op een logische wijze door de velden heenspringen, wordt het huidige proces amper aangetast. Steker nog, de applicatie vult zelf al een aantal velden in waardoor het proces wellicht sneller verloopt. Om het helemaal af te maken is er voor de experts een aparte versie van het programma beschikbaar. Deze versie opent, eenmaal opgestart, niet het overzichtsscherm als eerst, maar het storingsregistratie-formulier. Op deze manier kan de gebruiker direct beginnen aan het registreren van de storing.

LEERLINGEN De leerlingen zijn de experts in opleiding, welke vaak nog de hulp van een expert nodig hebben. Zij zijn niet in staat autonoom een storing te verhelpen. De focus qua gebruikersondersteuning ligt, en dit was het lastigst, op het aanbieden van relevante informatie betreffende de storing die verholpen moet worden. Voor deze uitdaging hebben we twee bronnen van informatie. Namelijk de storingen en de door ons bedachte kennisbank. Een zoekfunctie bied een eerste uitkomst. Zowel door de storingen, als de artikelen in de kennisbank, welke zijn geschreven door experts, kan worden gezocht. Handiger is echter als er daadwerkelijk een bepaalde koppeling is tussen oude storingen, die wellicht lijken op het huidige probleem, en een artikel in de kennisbank dat uitleg geeft hoe die storing is verholpen. Op deze manier wordt de leerling ondersteund in het proces van zelfstandig storingen oplossen. Deze koppeling is door ons gemaakt en kan, mits er artikelen bij oude storingen zijn geschreven, een extra hulp zijn in het oplossen van de storing. Kort samengevat: de zoekfunctie naar storingen zoekt naar vergelijkbare storingen. De gevonden storing is gekoppeld aan een of meer artikelen en biedt een mogelijke uitkomst voor de op te lossen storing.

ADMINISTRATIE De kerntaak van de administratie ligt in het rapporteren. Zowel het uitdraaien van grote vierwekelijkse documenten, maar ook het nog met de hand kunnen aanpassen van sommige teksten is belangrijk. Bovendien worden geregistreerde storingen gecontroleerd, afgevinkt en per email verstuurd in een kleine bundeling. Uiteindelijk ondersteunt het programma in elk van deze taken. Door een helder overzichtsscherm kunnen de storingen snel gezocht en afgevinkt worden. Bovendien zijn alle storingen apart of als selectie, of als vierwekelijkse periode te exporteren naar Rich Text Format. Eenmaal daar kan er, juist door dit formaat, via Microsoft Office Word of een andere tekst-editor nog een handmatige controle overeen alvorens het naar de klant gestuurd wordt. Ook wordt er voor elk van de documenten een inhoudsopgave volgens een vast stramien gegenereerd. Dit neemt aanzienlijk wat werk van de administratie uit handen.

48

8.

AANBEVELINGEN EN GEBREKEN

Hier beschrijven we aanbevelingen aan Tenuki en de TU. Ook worden enige onvolkomenheden en/of mogelijke uitbreidingen van de applicaties hier vermeld. Deze zullen aan de hand van de twee applicaties naar voren komen.

8.1

AANBEVELINGEN

TENUKI Voor Tenuki was werken met stage-personeel nieuw. We zullen hier omschrijven hoe wij bepaalde aspecten hebben ervaren en wat er wellicht in de toekomst, voor bijvoorbeeld een andere bachelor-stage, in onze ogen verbeterd zou kunnen worden.

BEGELEIDING De begeleiding vanuit Tenuki is goed verlopen. We hebben alle vier aan het begin van de stage een persoonlijke begeleider toegewezen gekregen. In Tenuki-taal: een koppel-mama of koppel-papa. Waarbij wij dan het kindje waren. Vooral in het begin, bij het wegwijs worden binnen Tenuki, was deze koppel-ouder handig. Op deze manier hoefde we niet steeds naar David of Mariska voor vragen, maar konden we gewoon op onze kamer de vragen die we hadden direct stellen. Bovendien is David de eerste twee, drie weken erg betrokken geweest met een goede opstart. Gedurende de stage is de begeleiding van David zijn kant langzaam aan minder geworden. Dat kon ook, omdat we wisten wat we moesten doen en hoe we het moesten doen. Inhoudelijk gezien, en dan met name voor Delphi, hebben we niet alle vier evenveel gehad aan onze koppelouder. Dan was het toch vaak David die te hulp moest schieten. De waarde van de de koppel-ouder werd dus gedurende de stage steeds minder. Om nu voor de begeleiding met een harde aanbeveling te komen is lastig, simpelweg omdat het goed verlopen is. Enige punt wat wellicht wat aandacht verdient is dat het mooi zou zijn geweest als de koppel-ouders ons vaker hadden kunnen helpen met Delphi.

TUSSENTIJDSE BEOORDELING Naast een stagevergoeding konden we, afhankelijk van inzet en resultaat, een variabele bonus verdienen. Het wel of niet krijgen van deze bonus werd medegedeeld tijdens de tussentijdse beoordeling. In dit gesprek, wat met David en Mariska werd gehouden, kwam onder andere ter sprake hoe het ging met de opdracht, of je werkomstandigheden goed waren en wat je er tot nu zo van vond. Aan de andere kant vertelde David en Mariska wat zij van ons vonden en waar punten van verbetering lagen. De tussentijdse beoordeling, maar ook de andere gesprekken, waren helder en zorgden voor wederzijds begrip. We bevelen het zeker aan om andere mogelijke bachelorgroepen op een zelfde manier te benaderen. Een bonus werkt over het algemeen stimulerend en is een leuke extra voor het verzette werk.

49

TU DELFT Dit jaar was er voor het eerst een combinatie van stage en bachelorseminarium. Hoewel wij wat betreft de stage voldoende tijd hadden, omdat deze tijd simpelweg gemaakt moest worden, werd de planning voor het bachelorseminarium af en toe best krap. Uiteindelijk is het goed afgelopen, maar een scheiding tussen stage en seminarium lijkt ons geen gek idee.

MONITORINGSYSTEEM Voor het monitoringsysteem zijn verschillende aanbevelingen te doen. Zo is er in de toekomst een nieuwe functionaliteit mogelijk voor het printen van de rapportages en kwamen we een tekortkoming in Delphi tegen (ontbrekende Windows API functie), die wellicht in een volgende versie verholpen kan worden.

RAPPORTAGE De scheiding tussen het monitoren en het rapporteren is groot bij het monitoringsysteem. Er zijn niet voor niets twee aparte applicaties ontwikkeld om deze functies te vervullen. Het rapporteren gebeurt, zoals eerder vermeld met XSL transformaties die XML documenten vorm kunnen geven. Deze documenten worden omgezet naar een leesbaar formaat en worden vervolgens met HTML en CSS opgemaakt. De HTML-documenten worden vervolgens geprint, gebundeld en naar de klant toe gezonden. Wellicht worden de documenten in de toekomst omgezet in PDF en via de e-mail naar de klant verstuurt. Om HTML-documenten te maken die mooi uit de printer komen, zijn momenteel een aantal handmatige instellingen vereist. Zo kan er in de internetbrowser waarmee de documenten geprint worden bij printerinstellingen ingesteld worden of het document kop- en voetteksten moet bevatten. Ook kan hier aangegeven worden of er een gekleurde versie, of een zwart-wit versie geprint moet worden. Al deze functionaliteiten kunnen in de toekomst geautomatiseerd worden met behulp van de derde CSS versie, CSS 3. Het instellen van de headers en footers wordt eenvoudig en mogelijk met behulp van de volgende ‘tags’ (zie tabel). Tabel 1: printen van header in CSS3 @page :left { @top-left { content: "Tekst linksboven in de header"; } }

Het wordt zelfs mogelijk om paginanummering toe te voegen aan de bestanden, zodat er een inhoudsopgave gegenereerd kan worden en de pagina’s overzichtelijk blijven. Paginanummering wordt mogelijk door middel van de volgende code (zie tabel): Tabel 2: printen van paginanummers in CSS3 @page :left { @bottom-right { content: counter(page); } }

Het is momenteel nog onduidelijk wanneer CSS 3 officieel als standaard geaccepteerd gaat worden. Maar we raden deze aanpassingen zeker aan, want de rapportage wordt op deze manier een echt rapport.

50

GEHEUGENSTATUS WINDOWS Binnen de Windowsversie van het monitoringsysteem wordt onder andere vrije en totale geheugenruimte gemeten. Dit verloopt met behulp van de functie: GlobalMemoryStatus, behorend bij de Windos API. Deze functie biedt echter onjuiste resultaten als het systeem een geheugenruimte heeft van meer dan 2 GB. Windows heeft hiervoor een opvolger gelanceerd, te weten: GlobalMemoryStatusEx. Deze functie is helaas niet te benaderen met de gebruikte versie van Delphi (7). Met een eventuele nieuwe versie van Delphi kan dit verholpen zijn en geeft het de juiste, correcte, informatie terug.

LOAD AVERAGE VOOR WINDOWS Na lang zoeken hadden we eindelijk een programma gevonden dat voor Windows, net als voor Linux een ‘Load Average’ kon berekenen. Dit getal geeft inzicht in de systeembelasting van een server en is dus ook interessant om te monitoren. Echter na wat testen bleek dat dit programma alleen werkte op Engelstalige Windows versies. We hebben hierover contact gehad met de ontwikkelaar en die zei bezig te zijn met een volgende versie waarin hij mogelijk dit probleem op zou lossen. Het is echter een hobbyproject van iemand en het is dus maar de vraag of en wanneer dit gaat gebeuren. We willen hier nog wel de link opnemen naar de website, zodat hier eventueel gecontroleerd kan worden of er een volgende versie voor uitgebracht is: http://www.arkane-systems.net/products/LoadAverage/index.aspx

STORINGSREGISTRATIE Voor het storingsregistratie systeem hebben wij enkele aanbevelingen. Het gaat hier om adviezen aan de lezer

KENNISBANK De kennisbank is ontwikkeld om het storingsregistratie systeem wat meer diepgang te geven. We hebben hier echter tijdens de stage niet de nadruk op gelegd, omdat de registratie en rapportage belangrijkere taken waren die ondersteund moesten worden. We hebben nog weinig feedback van de gebruiker op dit onderdeel gekregen. Onze aanbeveling is daarom om met de gebruikers (in het bijzonder de ‘leerlingen’) te overleggen of dit daadwerkelijk ondersteuning biedt tijdens het oplossen van een storing.

ZOEKEN NAAR STORINGEN EN ARTIKELEN Met het storingsregistratie systeem is het mogelijk om naar storingen en naar kennisbank artikelen te zoeken. De zoek functionaliteit die we hebben geïmplementeerd is niet erg uitgebreid of geavanceerd. Het zou voor de medewerkers van Tenuki (met name de administratieve medewerkers en de leerlingen) nuttig zijn om dit uit te breiden. Onze aanbeveling is om ‘AND’ en ‘OR’ zoekopdrachten mogelijk te maken. Denk hierbij aan invoer zoals bij bekende zoekmachines op het Internet mogelijk is.

51

8.2

GEBREKEN

SELECTIE VAN CHECKBOXES In de storingsadministratie applicatie maken we gebruik van een ListView met daarin twee kolommen met checkboxen. Deze checkboxen kunnen aan- en uitgevinkt worden. Echter als er een rij in de ListView geselecteerd wordt, en er wordt een ander scherm geopend, bijvoorbeeld een storingsregistratie scherm, dan blijft de achtergrond kleur van de kolommen met een checkbox blauw.

Figuur 18: Kleurverschil in de ListView

Dat komt omdat we deze kolommen met ‘CustomDraw’ tekenen op de ListView. We wisten wel hoe we de achtergrond kleur grijs moesten maken als het venster met de ListView geen focus had, maar dan kleurden de kolommen ook grijs i.p.v. blauw als we meerdere rijen selecteerden. Asako merkte dit eens op tijdens een gebruikerssessie, maar we hebben tot nu toe nog geen oplossing voor dit probleem kunnen vinden.

TAAKBALK GERELATEERDE PROBLEMEN De volgende onvolkomenheden hebben wij met onze kennis van Delphi niet op weten te lossen: Als vensters geminimaliseerd zijn, kunnen ze niet meer via ‘Vensters’ naar boven worden geroepen. De gebruiker moet dan echt in de taakbalk op het desbetreffende venster te klikken om het te openen. Als de gebruiker op het hoofdscherm klikt terwijl er storingsregistratie- of kennisbank vensters voor staan, is het logisch dat deze vensters dan minimaliseren. Dit gebeurt echter niet. Dit is een gevolg van de manier waarop we ervoor gezorgd hebben dat de nieuwe vensters (van storingen en artikelen) in de taakbalk van Windows verschijnen. Een oplossing voor bovenstaand probleem hebben we niet kunnen vinden. De bovenstaande problemen komen echter niet voor als de geopende vensters niet in de taakbalk geplaatst worden.

52

9.

EVALUATIES

In dit hoofdstuk kijken we kort terug op de stage opdracht en invulling die wij eraan gegeven hebben. Vervolgens zullen we alle vier vertellen wat we van het gehele project vonden, wat we hebben geleerd en hoe we het een en ander hebben ervaren.

9.1

PROJECT EVALUATIE

We hebben tijdens dit project gebruik gemaakt van een voor ons onbekende softwareontwikkelingsmethodiek, namelijk eXtreme Programming. In het begin was dat erg wennen, maar uiteindelijk zagen we de voordelen ervan. Door de kleine iteraties van twee weken en het veelvuldige overleg met de gebruikers, maakten we software die de gebruikers daadwerkelijk ondersteunden bij hun werkzaamheden. Het is moeilijk te zeggen dat dit niet gelukt zou zijn als we het watervalmodel gehanteerd hadden, maar we zijn ervan overtuigd dat de gekozen methodiek ons geholpen heeft om de ondersteunende software te ontwikkelen. Wat ons direct opviel aan de werkwijze van Tenuki is dat de codingstyle belangrijker was dan de comments in de code. Tenukianen hoeven namelijk geen comments in de code te schrijven, zolang de naamgeving van units, klassen, variabelen, procedures en functies maar consistent was. Wij hebben daarom dikwijls de ‘coding guidelines’ van Tenuki geraadpleegd en deze ook toegepast. We konden het echter niet laten om helemaal nergens comments toe te voegen aan de code, bij belangrijke of lastig te begrijpen code hebben we daarom toch comments toegevoegd. Een project zou geen project zijn als er geen dingen verkeerd gingen. We hebben een aantal zaken verkeerd aangepakt. We hebben bij de storingsregistratie applicatie bijvoorbeeld de 3-tier architectuur geïmplementeerd. Het leek ons belangrijk om deze driedeling te maken, omdat de code hier overzichtelijk van zou worden. Achteraf gezien bleek dat niet het geval. De gekozen architectuur zorgde voor een overhead aan code om met de database te communiceren. Het plan was om de server bepaalde logica uit te laten voeren voor bijvoorbeeld zoekopdrachten. Achteraf is er maar weinig logica geïmplementeerd en bleek de server (bijna) niet meer dan een doorgeefluik van data tussen de storingsregistratieapplicatie en de database. Het databasemodel van de monitoringapplicatie had ook uitgebreider gekund. We zijn bij de ontwikkeling de ‘redundante’ en minder gecompliceerde weg ingestuurd bij Tenuki. Dit was zeker in het begin handig voor ons en de implementatie verliep erg soepel. Later bleek dat het model wel iets gecompliceerder had gekund. Bij het toevoegen van een extra ‘check’, was het mooier geweest als die z’n eigen plek zou krijgen. Door onze keuze in het begin hebben we deze check ook in de vorm van de andere moeten gieten. Dit alles is geen groot probleem, maar wel iets om mee te nemen naar een eventueel volgend database ontwerp.

9.2

GROEPSEVALUATIE

Toen aan het begin van de stage duidelijk werd dat de monitoring en storingsregistratie twee verschillende applicaties nodig hadden, hebben we onze groep van vier in tweeën gesplitst. De twee MKT’ers Michel en Bas Wenneker zouden aan de storingsregistratie applicatie gaan ontwikkelen, terwijl de ST’ers Killian en Bas Schoenmakers de monitoringappplicatie voor hun rekening zouden nemen. De monitoringapplicatie was een technisch ingewikkelder project, maar bij de storingsregistratie applicatie was de user interface erg van belang. Daarom hebben we ervoor gekozen om de twee MKT’ers en de twee ST’ers aan verschillende applicatie te laten werken.

53

Het is echter niet zo dat we na deze tweedeling niets meer met elkaar te maken gehad hebben. We hadden alle vier nog weinig ervaring met de programmeertaal Delphi. Gedurende de hele stage hebben we elkaar ondersteund met tips en code voor bijvoorbeeld het meeschalen van de GUI, het gebruik van .ini configuratie bestanden, communicatie met de database, rapporteren in xml, en de keuze voor de n-tier architectuur. Tijdens de implementatie hebben we veel van elkaars code gebruikt en hebben we we elkaar ook veelvuldig geholpen met technische problemen. We hebben samen nagedacht over de architecturen en veel gecommuniceerd. De samenwerking verliep zeer goed en we zijn beide tot aan het einde van de stage bezig geweest met de twee applicaties. We kunnen terugkijken op een goed groepsproces.

9.3

KILIAN CROESE

Als ik terugkijk op de stagen bij Tenuki, kijk ik terug naar een leuke en leerzame tijd. In het begin was het wel even wennen aan de regelmaat van 4 dagen van 9:00 tot 17:30, maar dit wende gelukkig snel. Het werken met Delphi was ook leuk om te doen. In het begin was ik er, om heel eerlijk te zijn, niet heel enthousiast over. Echter naarmate ik er meer mee werkte, kwamen toch wel de sterke punten van Delphi naar voren. Het werken in projectvorm is altijd een leerzame ervaring. Het samenwerken en het afstemmen van de verschillende dingen die gedaan moeten worden is elke keer weer anders. Ik kan echter wel zeggen dan onze groep redelijk als een goede geoliede machine heeft samengewerkt. De vergaderingen waren efficiënt en er werd door iedereen hard, volgens de afspraken gewerkt. Ik ben hier dan ook zeer tevreden mee. Het belangrijkste dat ik geleerd heb tijdens deze stage is de eXtreme Programming aanpak. Gedurende de studie wordt hier een aantal keer heel kort op in gegaan, maar het wordt echter nooit echt bij een project gebruikt en daar leer je het pas echt. Het werken in kleine iteraties en zo je programma zien evolueren is echt heel leuk om te doen. Bij het watervalmodel ben je in het begin weken bezig met het schrijven van verslagen. Je ziet hier echter geen direct resultaat van. Bij XP volgen de ontwerp en implementatie delen elkaar snel op, zodat je dus snel het resultaat kan zien van wat je zojuist ontworpen hebt. Ik zie in XP heel veel voordelen en denk dat ik het in de toekomst dan ook zeker zal blijven gebruiken. Er is echter ook een groot gevaar bij XP, waar we bij het monitoringprogramma ook tegenaan zijn gelopen. Bij XP is het de bedoeling dat je het ontwerp zo simpel mogelijk wordt gehouden en dat je vooral geen rekening houd met uitbreidingen in de toekomst. Hierdoor hebben we dus in het begin voor een sterk vereenvoudigd dataontwerp gekozen. Echter in de loop van de stage kwamen er dingen bij die niet netjes in de bestaande datastructuur pasten. Hierdoor zou dus heel het ontwerp overhoop gegooid moeten gaan worden, met alle nadelen van dien. Ik denk dus dat ik in het vervolg iets langer en uitgebreider na ga denken over het dataontwerp en daar ook al wel rekening gaat houden met eventuele uitbreidingen. Aangezien je eigenlijk niet constant heel je datastructuur overhoop wilt gooien. Concluderend ben ik dus echt heel tevreden over de stage die ik gelopen heb bij Tenuki. Ik heb er een hele leuke tijd gehad en heb er ook echt ontzettend veel geleerd.

9.4

MICHEL FIEGE

De weken bij Tenuki zijn voorbij gevlogen en dat is doorgaans een goed teken. Ik heb het goed naar mijn zin gehad en veel ervaringen opgedaan. Delphi, wat een nieuwe taal voor me was, is me goed bevallen. Maar goed, een programmeertaal is doorgaans vervangbaar en lang niet zo belangrijk als de andere ervaringen die ik rijker ben geworden: eXtreme Programming, de Tenuki werkwijze, teamwork, plannen, presenteren, gebruikerssessies, vergaderen… Ik ben er al met al niet slechter van geworden, heb alles op me af laten komen en uiteindelijk denk ik een heleboel opgestoken.

54

Ik ben tevreden over hetgeen we hebben opgeleverd. Ook ben ik goed te spreken over de manier waarop het project is verlopen. Bovendien is het leuk om te zien dat ze het programma binnen Tenuki daadwerkelijk zullen gaan gebruiken.

9.5

BAS SCHOENMAKERS

Tenuki heeft mij een hoop bijgebracht. Niet alleen vond ik het leuk om een nieuwe programmeertaal te leren en te kunnen beheersen, ook heb ik veel opgestoken van het werkproces. De ervaring die voorbij is gevlogen, is voor mij een zeer geslaagde geweest. We leerden een nieuwe werkwijze, die er nog niet zo makkelijk in wilde. We hebben een aantal weken gedaan over het goed aanpakken en begrijpen van de manier waarop er bij Tenuki gewerkt wordt. Ik ben blij dat we de tijd hebben genomen voor deze fase. Het goed begrijpen van eXtreme Programming heeft ons proces versneld in de laatste weken van de stage. Het werken in fases beviel mij goed. Elke iteratie konden we laten zien wat we gedaan hadden en zagen we positieve reacties. Ook merkte ik dat we hierdoor weinig werk voor niets hadden gedaan. De gebruikers zagen wat ze wilden zien en kwamen met toevoegingen in plaats van wijzigingen (precies zoals we dat van te voren wilden zien), dat is een hele fijne ervaring geweest. De weekverslagen benadrukten elke week dat we goed bezig waren. Ik kon toch elke week weer een hoop dingen opschrijven die ik geleerd heb in de voorbije periode. Als ik mijn weekverslagen nu terug lees, zie ik opnieuw dat we iets moois hebben bereikt. Het samenwerken in de groep beviel mij goed. Natuurlijk wist ik van te voren wat ik aan de jongens had, maar het is altijd fijn om dit bevestigd te zien tijdens zo’n lange opdracht. De sfeer was gezellig binnen het bedrijf en het belangrijkste vind ik toch: we hebben bereikt wat we wilden bereiken. De stage bij Tenuki heeft mij qua werkwijze nog het meest bijgebracht. Ik ben ervan overtuigd dat ik facetten die ik hier heb opgepakt ga gebruiken in mijn verdere werk. Sterker nog, ik heb al gemerkt dat ik dingen die ik geleerd heb nu al aan het toepassen ben.

9.6

BAS WENNEKER

In eerste instantie had het bedrijf waar ik normaal voor werk gevraagd of ik voor hen een stageopdracht uit wilde voeren. Ik heb toen nee tegen hen gezegd omdat ik graag wilde zien hoe de aanpak bij een ander bedrijf was. Achteraf gezien ben ik erg blij dat ik voor Tenuki heb gekozen. De werkwijze van Tenuki is een werkwijze die ze op de TUDelft niet doceren. De werkwijze van Tenuki is erg gericht op de gebruiker en maakt gebruik van eXtreme Programming als programmeermethodiek. In het begin van de stage had ik wat moeite met de omschakeling van het watervalmodel naar eXtreme Programming. Naarmate de stage vorderde begreep ik steeds beter wat de werkwijze precies inhield en hoe ik deze toe moest passen. Ik ben er zeker van dat ik deze werkwijze nog vaak zal toepassen. Daarnaast was de sfeer binnen Tenuki altijd goed. Ik heb geen enkel moment het gevoel gehad dat we de Tenukianen voor de voeten liepen. Ze bleven alle tijden vriendelijk en behulpzaam. Af en toe, voor belangrijke deadlines, was de spanning te voelen. Maar dat duurde nooit lang. Ik ben dankbaar voor de leuke en leerzame periode bij Tenuki.

55

REFERENTIES LITERATUUR Lischner, Ray. 2000. Delphi in a nutshell, A Desktop Quick Reference. O’Reilly & Associates, Sebastopol. Taylor, Don & Mischel, Jim & Gentry, Tim. 2001.Kylix Power Solutions. Coriolis, Scottsdale. Beck, Kent. 2005. Extreme programming explained: embrace change. Pearson Education, Inc.

INTERNET Internet is wat betreft informatievoorziening van zeer grote waarde geweest voor ons project. Hoewel er niet is bijgehouden wanneer wij welke links hebben geraadpleegd, willen wij hieronder toch onze linkbase, zoals wij die op Trac hebben bijgehouden, voor de volledigheid van dit rapport toevoegen.

DELPHI TUTORIALS http://delphibasics.co.uk/ http://delphi.wikia.com/wiki/Main_Page http://directory.google.com/Top/Computers/Programming/Languages/Delphi/ http://www.nldelphi.com/ http://www.festra.com/ http://sheepdogguides.com/dt100/dt100index.htm http://delphi.startpagina.nl/ http://www.chami.com/tips/delphi/

DUNIT TUTORIALS http://www.nldelphi.com/cgi-bin/articles.exe/ShowArticle?ID=14697 http://dunit.sourceforge.net/README.html

INTERBASE http://www.felixcolibri.com/papers/db/interbase/turbo_delphi_interbase_tutorial/turbo_delphi_interbase_tutorial.html#creat e_database http://www.ibphoenix.com/main.nfs?a=ibphoenix&s=1123813924:136594&page=ibp_ibx http://mc-computing.com/Databases/Delphi/Database_Connections_firebird.html http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_15minutes

56

RAVE (REPORT AUTHORING VISUAL ENVIRONMENT) http://www.nevrona.com/Default.aspx?tabid=150 http://www.nevrona.com/Rave/downloadbe.html http://www.nevrona.com/files/rant.txt http://www.nevrona.com/Default.aspx?tabid=152#IntroRaveI

LAYOUT http://delphi.about.com/od/objectpascalide/l/aa042500a.htm http://delphi.about.com/od/vclusing/l/aa101299.htm http://dn.codegear.com/article/32047

SSH-VERBINDING MET DELPHI http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_20752651.html http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_20751335.html PLink Download PLink documentatie

RDP PASSWORD ENCRYPTIE http://www.remkoweijnen.nl/blog/2007/10/18/how-rdp-passwords-are-encrypted/

DELPHI 7 ONDER VISTA DRAAIEN http://www.drbob42.com/examines/examin84.htm

CHARTS MET DELPHI ftp://ftp.sybex.com/2565/2565ch22k.pdf Using TeeChart?(vanaf pagina 55) http://www.steema.com/products/teechart/getting_started_with_teechart_pr.htm

SECURE SOCKET MET INDY LIBRARIE http://www.indyproject.org/Sockets/Demos/index.EN.aspx http://adg.bmpcoe.org/IndySSL/

WINDOWS SYSTEM TRAY http://delphi.about.com/od/kbwinshell/l/aa121801a.htm 57

WINDOWS LOAD AVERAGE http://www.teamquest.com/resources/gunther/display/5/index.htm http://gathering.tweakers.net/forum/list_message/24812077#24812077 http://gathering.tweakers.net/forum/list_messages/814910#loadavg http://www.arkane-systems.net/products/LoadAverage/index.aspx

ACCELERATOR KEY http://www.delphicorner.f9.co.uk/articles/comps3.htm

CAPTURE THE OUTPUT FROM A DOS (COMMAND/CONSOLE) WINDOW http://delphi.about.com/cs/adptips2001/a/bltip0201_2.htm

CSS PRINTEN http://www.alistapart.com/articles/boom

58

BIJLAGE 1: ONTWERP GUI In deze bijlage nemen we de schetsen op die zijn gemaakt als ontwerp van de grafische user interface. Deze zijn gegroepeerd per systeem per iteratie.

MONITORINGSYSTEEM OORSPRONKELIJK ONTWERP

Figuur 19: Hoofdscherm origineel ontwerp

59

Figuur 20: Monitoringscherm origineel ontwerp

60

Figuur 3: Configuratie scherm origineel ontwerp

61

ITERATIE 1

Figuur 22: Hoofdscherm fase 1

Figuur 23: Monitoringscherm fase 1

62

Figuur 44: Overzichtscherm fase 1

Figuur 25: Rapportagescherm fase 1, met XML formaat

63

ITERATIE 2

Figuur 26: Hoofdscherm fase 2

64

Figuur 27: Overzichtscherm fase 2

65

Figuur 28: Monitoringscherm fase 2

Figuur 29: Rapportagescherm fase 2

66

STORINGREGISTRATIESYSTEEM ITERATIE 1

Figuur30: Storingsregistratie invoer scherm.

67

Figuur 31: Storingsregistratie invoer scherm

68

Figuur 32: Storingsregistratie overzicht

Figuur 33: Kennisbank overzicht fase 1

69

Figuur 34: Zoeken naar storingen en kennisbankartikelen

70

BIJLAGE 2: GUI RESULTATEN

Figuur 35: Monitoring, bezig met monitoren

Figuur 36: Monitoring, overzicht na een monitoring

71

Figuur 37: Monitoring, harde schijf resultaten

Figuur 38: Monitoring, resultaten opslaan

72

Figuur 39: Storingsregistratie, overzichtsscherm van de storingsmeldingen

Figuur 40: Storingsregistratie, toevoegen nieuwe storingsmelding

73

Figuur 41: Storingsregistratie, zoeken naar storingsmeldingen

Figuur 42: Storingsregistratie, kennisbank overzicht + zoeken. Hier wordt bevestiging gevraagd om artikel te verwijderen.

74

Figuur 43: Storingsregistratie, kennisbank artikel toevoegen

Figuur 44: Storingsregistratie, exporteren van storingsmeldingen. Op de achtergrond is een gedeelte van het overzicht zichtbaar.

75

Figuur 45: Storingsregistratie, inhoudsopgave (RTF) na exporteren.

Figuur 46: Storingsregistratie, storingsmelding opgemaakt door middel van RTF.

76

BIJLAGE 3: ONDERZOEKSVERSLAG

OPDRACHTOMSCHRIJVING In dit hoofdstuk zullen we de gegeven opdrachtomschrijving verder uitwerken. We zullen eerst de omschrijving die gegeven is door het bedrijf opnemen, waarna we een analyse maken van de verschillende dingen die gedaan moeten worden en verder uitleggen wat dit precies inhoud.

OMSCHRIJVING Eén van de belangrijkste, stabiele stroom van inkomsten voor Tenuki is het 24-uurs beheer- en onderhoudscontract met de belangrijkste klant Rijkswaterstaat. De draaiende systemen voor de file-informatie dienen dag en nacht bereikbaar te zijn. Naast het feit dat Tenuki ieder moment van de dag gebeld kan worden voor optredende storingen, behoort tot deze taak het dagelijks (momenteel 2x daags) monitoren van de verschillende systemen. Het monitoren en de verslaglegging is momenteel behoorlijk tijdrovend handwerk, waarbij ook nog eens per maand een aparte monitoringrapportage opgesteld dient te worden voor de klant. Ook de registratie van storingen en het vastleggen van de verrichte acties is handwerk. Deze laatste rapportages worden in vrije tekst opgesteld en ook eens per maand apart gebundeld voor de klant. De uitdaging is om alle onderdelen, van monitoring tot storingsrapportages, te automatiseren, waarbij het voor de beheerders werkbaar blijft.

OPDRACHT Maak een intranet-oplossing waarmee automatisch gemonitord kan worden. Tevens moet het mogelijk zijn om storingen te registreren. Hiernaast dient een tool ontwikkeld te worden waarmee de maandrapportages eenvoudig gegenereerd kunnen worden.

ANALYSE Na het goed bestuderen van de opdrachtomschrijving en enkele besprekingen met het bedrijf kunnen we de opdracht opsplitsen in 2 delen, die elk ook weer uit 2 delen bestaan, te weten: Een overzicht: 1.

2.

Monitoring a. Met regelmaat monitoren van de verschillende servers, momenteel 2x per dag b. Het opstellen van een maandelijkse monitoringrapportage Storingen a. Het rapporteren van inkomende storingen en de uitgevoerde handelingen. b. Het samenstellen van een storingsrapportage

Doordat er storingen zijn vastgelegd in een database kunnen hier wellicht oplossingen voor nieuwe storingen. Er dient een handige manier gevonden te worden om deze storingen te doorzoeken. 77

MONITORINGSSYSTEEM Zoals gezegd worden de systemen van Rijkswaterstaat momenteel 2x per dag handmatig gecontroleerd. Momenteel maakt een werknemer verbinding met de verschillende servers die gecontroleerd moeten worden en kijkt of de huidige waarden van onder andere de CPU, het geheugen en de harde schijf normale waarden vertonen. Verder wordt gecontroleerd of de essentiële services draaien en nog reageren. Verder moet er gerapporteerd worden wanneer er problemen optreden. Als een harde schijf bijvoorbeeld bijna vol is moet er gerapporteerd worden dat de harde schijf bijna vol is en eventueel moet de beheerder (automatisch) gewaarschuwd worden. De opdracht is om een programma te maken dat de werknemers bij Tenuki ondersteunen tijdens het monitoren. Deze kan vervolgens controleren of alles nog naar behoren draait. Wellicht kunnen sommige ‘checks’ automatisch door het programma uitgevoerd worden. Dit zal gebeuren door een vergelijking met vorige resultaten en met zelf bepaalde constraints. Zo kan er bijvoorbeeld een melding gemaakt worden als een bepaalde server nog maar 300Mb aan vrije schijf ruimte heeft. Deze gegevens worden in een database opgeslagen, zodat er een frontend geschreven kan worden, waar al deze gegeven makkelijk inzichtelijk zijn gemaakt. Dit zal dus gebeuren door middel van bijvoorbeeld grafieken. De maandelijkse rapportages die naar de klant worden verstuurd worden, kunnen ook automatisch aangemaakt worden. Alle gegevens van de afgelopen maand staan in de database.

STORINGREGISTRATIESYSTEEM Ook worden er storingen gemeld bij Tenuki, bijvoorbeeld via de telefoon of via SMS. Deze storingen worden momenteel gewoon opgeslagen in een tekstbestandje en deze worden maandelijks gebundeld en naar de klant gestuurd. Deze rapportages zijn het bewijs dat er gewerkt is en wat er precies is uitgevoerd. Momenteel wordt er nog veel dubbel werk uitgevoerd. De storingen worden veel overgetikt en gekopieerd. Aan ons de taak om een eenduidige structuur op te stellen, waardoor de werknemer slechts 1 formulier in hoeft te vullen. De gegevens uit dit formulier kunnen worden opgeslagen in een database, zodat er een mooi overzicht te creëren is. Dit overzicht kan vervolgens naar de klant gestuurd worden.

KNOWLEDGE BASE Aangezien alle storingsrapportages in de database opgeslagen staan, kunnen deze ook voor andere doeleinden gebruikt worden dan het opmaken van verslagen. Zodra er momenteel een storing optreed, zal de kennis van de werknemer het middel zijn om de storing te verhelpen. De werknemer heeft tenslotte ervaring met de huidige systemen en weet snel wat er zou kunnen mankeren. Een nieuwe werknemer zal echter gebruik kunnen maken van een knowledge base. Met deze knowledge base kunnen alle storingsrapportages uit het verleden bekeken worden. Zodoende kan een fout die zich eerder voor heeft gedaan snel verholpen worden. De taak voor ons is om een inzichtelijk programma te schrijven, zodat de werknemer zijn weg in de knowledge base snel gevonden heeft en zodoende tot een snelle oplossing komt.

78

EXTREME PROGRAMMING Extreme Programming is een software ontwikkelingsmethodiek die een aantal ontwikkelprincipes combineert en tot in het extreme doorvoert (vandaar de naam eXtreme Programming). De methode is vooral bedoeld voor klantspecifieke software oplossingen (maatwerk), waarbij de specificaties van het systeem vooraf nog niet volledig bekend hoeven te zijn. Door het iteratieve karakter van Extreme Programming kunnen ontwikkelaars beter om gaan met wisselende requirements van de klant. Voordat we ingaan op de werking van eXtreme Programming, is het belangrijk te weten waarom eXtreme Programming voordelen oplevert boven andere ontwikkelmethodieken. De huidige methodieken zijn gebaseerd op de veronderstelling dat de kosten om software aan te passen exponentieel toenemen in de tijd. Dat wil zeggen dat de kosten van aanpassingen aan software dat al in gebruik is genomen hoger liggen dan de kosten voor dezelfde aanpassing tijdens de ontwikkelperiode. Extreme Programming zorgt ervoor dat code aangepast kan worden met licht lineair stijgende kosten, i.p.v. exponentieel stijgende kosten. Mede hierdoor is het niet noodzakelijk om voor aanvang van het project alle requirements te hebben, maar het is wel gewenst. Anders gezegd, zonder een volledige specificatie kan er begonnen worden aan de ontwikkeling van het systeem. In de volgende paragrafen zal uitgelegd worden hoe eXtreme Programming de exponentieel oplopende kosten kan beperken.

FEEDBACK Bij eXtreme Programming wordt de klant nauw betrokken bij het ontwikkelproces. Met behulp van de klant worden usecases opgesteld. Dit gebeurd aan de hand van interviews die met de klant gehouden wordt. Deze usecases bevatten geen functionele specificaties, maar geven scenario’s weer van huidige bedrijfsprocessen. In het bedrijfsleven komt de vraag naar software vaak van degenen die de bevoegdheid hebben om beslissingen te maken en die beschikken over geld. Vaak zijn het dus de managers of leidinggevenden die specificaties van het systeem geven. Naast de gegeven specificaties worden dus nog interviews gehouden met de eindgebruikers van het te ontwikkelen systeem. De eindgebruikers zijn meestal de werknemers op de werkvloer, en niet de leidinggevenden zelf. De ontwikkelaars zullen alleen maken wat uit de requirements blijkt. Er zal geen extra functionaliteit toegevoegd worden, zonder dat de klant daarom vraagt. Het ontwikkelproces kan versnelt worden als er een toekomstige gebruiker regelmatig of altijd beschikbaar is om vragen aan te stellen. Extreme Programming maakt gebruik van korte iteraties, waarin steeds andere test cases geïmplementeerd zullen worden. Na iedere iteratie wordt het systeem beoordeeld door de klant. Hierdoor kunnen eventuele misstappen in een vroeg stadium opgevangen worden.

UNIT TESTS Met unit tests kunnen functionele stukken code onafhankelijk van elkaar getest worden op correcte in- en uitvoer. Door unit tests te schrijven wordt refactoring van code mogelijk. De unit tests moeten allemaal 100% slagen voordat een systeem opgeleverd wordt of voordat een tussentijdse review wordt gehouden.

79

REFACTORING Dit ontwikkelprincipe is het herschrijven van stukken code, zonder dat de interface veranderd. De invoer en uitvoer van de code moet hetzelfde blijven, en er wordt geen functionaliteit aan het systeem toegevoegd. Voordat er aan refactoring begonnen kan worden, moeten er unit tests voor handen zijn. Met deze unit tests kan de in- en uitvoer van de herschreven code direct getest worden. Refactoring wordt vaak toegepast voordat er nieuwe functies worden toegevoegd aan bestaande code.

EENVOUD VAN ONTWERP Extreme Programming schrijft voor dat altijd voor het simpelste ontwerp gekozen moet worden. Zoals al eerder in de paragraaf Feedback geschreven werd, wordt er bij XP alleen de functionaliteit geïmplementeerd waar om wordt gevraagd. Bij het maken van een ontwerp hoeft dus niet nagedacht te worden over toekomstige aanpassingen of uitbreidingen. Het is immers zo dat XP aanpassingen aan een bestaand systeem geen (exponentieel groeiende) extra kosten met zich meebrengt. Daarnaast is het goed mogelijk dat een doordacht ontwerp later niet meer voldoet aan de (nieuwe) requirements.

PAIR PROGRAMMING Pair Programming is een belangrijk ontwikkelprincipe binnen de XP methodiek. Bij Pair Programming zitten twee ontwikkelaars achter één computer. Dit principe verbetert de kwaliteit van de programmatuur. Het is niet intuïtief, maar twee ontwikkelaars werkend op dezelfde computer zijn even productief als twee afzonderlijk werkende ontwikkelaars, alleen verminderd Pair Programming het aantal bugs. Hierdoor is deze manier van werken zelfs krachtiger dan systematisch testen (met unit tests). Door de hoge kwaliteit van de programmatuur worden uiteindelijk kosten bespaard. Bij Tenuki wordt Pair Programming meestal achterwege gelaten. De techniek wordt alleen toegepast bij het maken en/of verbeteren van cruciale onderdelen. Het wordt ook gebruikt vlak voor het verlopen van deadlines om fouten te voorkomen die gemaakt worden als een programmeur onder hoge druk verkeert.

80

PLAN VAN AANPAK In dit plan van aanpak gaan we voornamelijk beschrijven wat we willen gaan maken en richten ons minder op de manier waarom we dat gaan doen. Dit zal uit 2 en programma’s bestaan. Ten eerste zullen we een programma gaan maken die de gebruiker ondersteunt bij de monitoringstaken. Ten tweede zal er een programma worden gemaakt waar storingen in verwerkt kunnen worden. Hierbij zou een onderdeel kunnen worden gemaakt waarmee rapportages samengesteld kunnen worden. Verder zou er een knowledge baseachtig onderdeel gemaakt kunnen worden. Waarin vorige storingen makkelijk te doorzoeken zijn.

MONITORINGSPROGRAMMA Het monitoringprogamma heeft als doel om de gebruiker te ondersteunen bij de monitoringstaken. Zoals eerder al gemeld is, wordt er nu handmatig verbinding gemaakt met een server en worden de gegevens in de console gecontroleerd. Ook moeten er rapportages gemaakt worden over de bevindingen van de monitoringen.

MONITORING Wat we kunnen gaan maken is een programma die verbinding maakt met de servers en de actuele gegevens op een overzichtelijke manier aan de gebruiker presenteert. Hierbij zouden gegevens van vorige monitoringen getoond kunnen worden, zodat een goede vergelijking kan worden gemaakt. Verder zouden er per systeem bepaalde waarschuwingstresholds opgesteld kunnen worden. De gebruiker zou dan bijvoorbeeld door het programma gewaarschuwd kunnen worden dat de harde schrijf van server X te vol is.

RAPPORTAGE Een belangrijk deel van de monitoring is de rapportage. Momenteel worden de gemaakte tekstbestandjes verwerkt tot een mooi rapport. Wanneer we de gegevens op gaan slaan in bijvoorbeeld een database kan er functionaliteit gemaakt gaan worden die helemaal automatisch een rapport samenstelt of anders de gebruiker helpt bij het samenstellen van een dergelijk rapport. Over een aantal dingen is het wel nuttig om hier te zeggen hoe we het gaan doen. Het programma zal namelijk in Delphi geschreven gaan worden. Dit omdat het programma onderhouden en eventueel uitgebreid moet gaan worden door Tenuki. Verder zijn er niet veel voordelen van een webbased aanpak. Verder is er ook een hoop kennis over Delphi in huis bij Tenuki. Wat een mooie gelegenheid is om een hoop te leren. Verder zullen de gegevens worden opgeslagen in een database, zodat de gegevens op een overzichtelijke manier worden opgeslagen en we hier eenvoudig ook met andere programma’s verbinding mee kunnen maken.

81

STORINGSRAPPORTAGEPROGRAMMA Het storingsprogramma gaat gebruikt worden om storingen op een uniforme manier in op te slaan. Verder kan dit programma gebruikt gaan worden om rapportages mee samen te stellen. En tot slot kunnen de vorige storingen toegankelijk gemaakt worden, zodat men kan leren van vorige storingen.

INVOERING STORINGEN Op dit moment worden de storingen nog bijgehouden in plain tekst bestandjes. Wat we gaan maken is een programma die grotendeels de huidige opzet zal blijven volgen, waarbij de storingen op een uniforme manier ingevoerd kunnen worden.

RAPPORTAGE Ook bij het verwerken van storingen zijn rapportages belangrijk. Daarom zal er net als bij de monitoring soortgelijke functionaliteit gemaakt worden voor een storingsrapportage.

KNOWLEDGE BASE Wat we eventueel nog zouden kunnen maken is een knowledge base. Dit is functionaliteit die de storingen op een logisch manier inzichtelijk gaat maken. Hierdoor kunnen dus bijvoorbeeld vorige storingen makkelijk worden opgezocht, zodat er geleerd kan worden van de vorige aanpak.

82

DE VERSCHILLEN TUSSEN JAVA, PHP EN DELPHI Aangezien onze kennis van Delphi op dit moment gering is, onderzoeken we de verschillen tussen Delphi en twee talen die wij wel goed kennen: Java en PHP.

Paradigma’s

Java Imperatief ObjectgeoriënteerdGeneriek

Type strength Type checking Type safety

Sterk Statisch Veilig

PHP Imperatief Object-georiënteerd Reflectief Zwak Dynamisch n.v.t.

Overerving Garbage collector

Enkelvoudig Ja

Enkelvoudig Nee, reference counting

Delphi Imperatief Object- georiënteerd Generiek Sterk Statisch Veilig (maar onveilig is toegestaan) Enkelvoudig Nee

IMPERATIEF Het imperatieve paradigma beschrijft programma’s als opdrachten die de state van een programma aanpassen. Het beschrijft de acties die achter elkaar worden uitgevoerd.

OBJECT GEORIËNTEERD Dit paradigma maakt gebruikt van objecten en hun interactie om programma’s te ontwerpen. Er komen vele technieken bij kijken waaronder inkapseling, modulariteit, polymorfisme en overerving.

GENERIEK Generiek programmeren is een soort meta-programmeren, waarbij de syntax en semantiek enigszins kan worden uitgebreid. Een bepaalde functie hoeft bijvoorbeeld niet te weten op wat voor soort datatype het werkt, het gaat er om hoe de functie werkt.

REFELECTIEF Bij reflectief programmeren kan een programma zijn eigen structuur en gedrag overzien en aanpassen. Het reflectieve paradigma stelt dat de volgorde van opdrachten niet per se besloten is tijdens compiler tijd. Deze volgorde is dynamisch, afhankelijk van data op bijvoorbeeld runtime niveau.

TYPE STRENGTH Strong typed wil zeggen dat het er toe doet met wat voor datatype we te maken hebben. Als een functie bijvoorbeeld een verkeerd type parameter krijgt zal de functie falen. Bij Weak typing converteert de taal de variabele zoals nodig is.

TYPE CHECKING Dit heeft te maken name binding. Statisch binden of vroeg binden gebeurt voordat het programma geëxecuteerd wordt. Het binden tijdens runtime heet dynamisch of laat binden.

83

TYPE SAFETY Een taal wordt Type safe genoemd als het geen operaties of conversies toestaat die tot fouten leidt.

OVERERVING Dit is een van de technieken die bij Object-georiënteerd programmeren komt kijken. Er kan zo bijvoorbeeld een klasse (subklasse) worden gecreëerd uit een andere klasse (superklasse). De subklasse erft alle eigenschappen van de superklasse. Enkelvoudige overerving laat slechts het erven van 1 superklasse toe.

GARBAGE COLLECTOR Dit is een vorm van automatisch geheugenbeheer. De GC probeert geheugen vrij te geven van objecten die niet meer in gebruikt zijn in de applicatie. PHP maakt gebruik van een oudere variant van de GC en dit is reference counting. Deze techniek is trager.

84