LEERKERN

4.1 Fasen in het ontwikkeltraject

Introductie

Hoewel men het er in grote lijnen wel over eens is welke fasen in een ontwikkeltraject doorlopen moeten worden, worden in de literatuur soms verschillende termen gebruikt om deze fasen aan te duiden. Een veelgebruikte indeling is: analysis, specification, design’, implementation, testing, maintenance. Stefik onderscheidt de fasen: ‘Identification’, ‘Conceptualization’, ‘Formalization’, ‘Implementation’ en ‘Testing’. Stefik onderscheidt geen aparte fase voor het vastleggen van de specificaties, maar maakt wel onderscheid tussen de verschillende ontwerpfasen: ‘conceptualization’ en ‘formalization’. Omdat de onderhoudsfase niet mag ontbreken, is deze aan de indeling van Stefik toegevoegd.

Lees uit Stefik paragraaf 3.3.3 tot ‘Process versus product (pagina’s 349 tot en met 351).

4.1.1 Identificatie

In de identificatiefase wordt een analyse gemaakt van het probleem en de eisen die aan het kennissysteem worden gesteld. Wat houdt het probleem precies in? Kan het worden opgelost met een kennissysteem? Wat is het doel van het systeem precies? Wat zijn de wensen van de gebruikers? Aan welke eisen moet het systeem voldoen? Om een antwoord te vinden op deze vragen, zijn er verschillende activiteiten binnen de identificatiefase: een haalbaarheidsstudie om te bepalen of het ontwikkelen van een kennissysteem haalbaar en de moeite waard is (zie ook hoofdstuk 3, paragraaf 3.1), kenniselicitatie om inzicht te krijgen in het domein (zie ook hoofdstuk 3, paragraaf 3.2) en een inventarisatie van gebruikerswensen en een organisatieanalyse.

Een organisatiemodel ondersteunt de analyse van de betreffende organisatie en maakt het mogelijk om voorspellingen te doen over cruciale factoren in het ontwikkelproces, zoals gebruiksvriendelijkheid, integratie en effectiviteit en aspecten als de kwaliteit van de beschikbare middelen, de mate van training van de projectmedewerkers en de aard van de ondersteuning van toeleveranciers.

Zoals gezegd, besteedt Stefik weinig aandacht aan de manier waarop de specificatie van eisen van het systeem wordt vastgelegd. De resultaten van de analyse worden meestal in een projectdefinitie vastgelegd. Dit document beschrijft de huidige en gewenste situatie met als doel het identificeren van bottle-necks in de huidige situatie, het vastleggen van de wensen van de gebruikersorganisatie en het te voeren beleid om te komen tot de gewenste situatie. Het bevat alle mogelijke eisen met betrekking tot gewenste functionaliteit, gebruikers-interface, hardware, performance, enzovoorts en extra aandacht voor het identificeren van problemen met betrekking tot de te modelleren kennis. Daarnaast bevat het een inschatting van de kosten van het project.

4.1.2 Conceptualisatie

Tijdens de conceptualisatiefase wordt het systeem op kennisniveau gedefinieerd. De relevante kennis wordt geformuleerd in termen van modellen, taakstructuur en oplossingsmethode. Hoofdstukken 10, 11 en 12 gaan verder in op representaties op kennisniveau. In deze hoofdstukken komen generieke modellen voor respectievelijk classificatie, configuratie en diagnose aan de orde. De resultaten van deze fase worden vastgelegd in een zogeheten functioneel ontwerp. Dit document is leesbaar voor de opdrachtgever en gebruikers, zodat deze zich een beeld kunnen vormen van het toekomstig systeem en of het voldoet aan hun verwachtingen. Het functioneel ontwerp vormt tevens het uitgangspunt voor de volgende fase, de formalisatie.

4.1.3 Formalisatie

Tijdens de formalisatiefase wordt de kennis op symboolniveau vastgelegd. Door deze formalisatie is het mogelijk de kennis in een systeem vast te leggen en kan het systeem gebruik maken van de kennis. In de formalisatiefase staan keuzes voor kennisrepresentatie, algoritmen en redeneermechanismen centraal. Omdat binnen de kennistechnologie heuristische kennis vaak een rol speelt, is formalisatie vaak ingewikkelder dan het opstellen van een algoritme. Het maken van een keuze voor een bepaalde representatie verdient dan ook extra aandacht. Het verder formaliseren en procedureel preciseren van de relevante kennis leidt tot een nieuw document: het technisch ontwerp. Meer over symbolen en kennisrepresentatie vindt u in hoofdstukken 6, 7, 8 en 9.

4.1.4 Implementatie

Het technisch ontwerp wordt uitgewerkt naar het niveau van een werkend computerprogramma voor de gebruikers in hun omgeving. Daarbij wordt ook de hardware- en software-context meegenomen voor het specificeren van de technische details.

Deze representatie op implementatieniveau omvat de gespecificeerde domein- en procedurele kennis in een eindontwikkelomgeving. Het ontwerp wordt omgezet in code met behulp van een programmeer-tool of een bredere ontwikkelomgeving.

Tenslotte moet het kennissysteem worden ingebed in de organisatie. Factoren die naar voren zijn gekomen bij het maken van het organisatiemodel, dienen te worden meegenomen bij de invoering van het systeem. Deze stap moet niet worden onderschat. De uiteindelijke acceptatie van een systeem kan een cruciale succesfactor blijken te zijn.

4.1.5 Testen

Als het computerprogramma klaar is, dan dient het te worden geïnstalleerd en getest.

Alle resultaten van het gehele traject moeten worden geëvalueerd op alle doelstellingen die voor het project zijn gedefinieerd. Dit beperkt zich dus niet tot alleen de vraag ‘Werkt het computerprogramma volgens de afspraken?’, maar ook ‘Waren de afspraken voldoende?’, ‘Is de accepatie en inbedding in de organisatie goed verlopen?’, ‘Waar liggen eventuele verbeterpunten’ en ‘Wat moet er nu nog gebeuren?’ Het gaat dus zowel om verificatie (werkt het systeem correct, dat wil zeggen: volgens de specificaties) als om validatie (is het een correct systeem, dat wil zeggen, een systeem met de juiste specificaties). Vooral bij dit laatste kan een gebruikstest in een bruikbaarheidslaboratorium nuttig zijn.

4.1.6 Onderhoud

Wanneer het kennissysteem in gebruik is genomen, breekt de onderhoudsfase aan. Als er iets verandert in de organisatie of de gebruikte kennis, moet het systeem mee veranderen. Kennissystemen zijn over het algemeen makkelijker onderhoudbaar dan conventionele systemen, omdat de kennis niet verweven is in code, maar bijvoorbeeld gerepresenteerd in aparte kennisregels. Toch moet de onderhoudsfase niet worden onderschat. Net als bij conventionele systemen, moet een bedrijf over de juiste inrichting beschikken om dit serviceniveau, het onderhoud van een kennissysteem, waar te maken.

> Opgave 4.1.1

> Opgave 4.1.2