Raamwerk Diagram – LABIRINT
Labirint Beschrijving Het BEDRIJFSARCHITECTUUR - Raamwerk - LABIRINT is gebaseerd op het "Zachman Framework" (http://www.zifa.com). Succesvolle bedrijven integreren IT-organisatie, IT-prioriteiten en IT-ontwikkelingsprojecten met strategie, visie, missie, enz. op een systematische manier om te verzekeren dat de IT-systemen de doelstellingen en de processen van het bedrijf op een EEE-wijze ondersteunen. Het LABIRINT raamwerk is een manier om dit te verwezenlijken. Het raamwerk is niet “HET” antwoord. Het is een referentiekader, een hulpmiddel dat helpt bij het denken over deze integratie en dat communicatie heel wat gemakkelijker maakt.
Behoeftedefinitie (cel 0) Doel: Insteek en scoping van ‘een project’. Onderzoek naar reeds beschikbare diagrammen (logische, technische en constructie). Resultaat: Visiedocument: bevat relevante gegevens uit andere cellen voor vastleggen van duidelijke scoop van het project. Beschrijving: Deze documenten bevatten de behoeftedefinitie informatie. Eerst wordt een korte omschrijving van de probleemstelling gegeven. Daarna wordt beschreven welke personen en organisaties (belanghebbenden) beïnvloed worden in het probleemgebied. Afzonderlijk worden de toekomstige gebruikers of actors van het systeem opgesomd. Vervolgens wordt een opsomming gegeven van alle behoeften. Per behoefte wordt bepaald wat de inschatting van de kosten, de resources, het technisch risico en prioriteit bij de klant is. Ook wordt vermeld in welke Use Case de behoefte wordt opgenomen en in welke versie (iteratie) van het project de behoefte wordt meegenomen. In een volgend onderdeel worden de technische behoeften besproken: eisen wat performantie, stabiliteit, responsetijden, aantal concurrent users e.d. Welke behoeften niet worden opgenomen in het project worden ook beschreven. Elk van de niet weerhouden behoeften moet met redenen gestaafd worden. Een afzonderlijk gedeelte handelt over de technische beperkingen van het systeem en waarom deze beperkingen gelden. Een keuze wordt uit de verschillende mogelijke oplossingen gemaakt.
Logische Diagrammen / Analyse (cellen 14 t.e.m. 18) Doel: IT-gerichte analyse van het “te automatiseren” bedrijfsgebied in de taal van de klant / toekomstige gebruiker. Eenduidig vastleggen van de doelstellingen van een IT-project (gebruikers, logische data, input, output, look-and-feel, ...). Fundament geven aan het management voor een doordachte beslissing over het al dan niet automatiseren van een probleemgebied in het bedrijf. Resultaat: Voor de klant / gebruiker leesbaar document opgebouwd met relevante informatie uit de cellen, conform bedrijfsfilosofie van de klant.
Functionaliteiten diagram - interactie tussen actoren en systeemonderdelen (cel 14) Beschrijving De functionaliteiten (use-cases) brengen de interactie tussen gebruiker en de systeemonderdelen in kaart. Deze diagrammen geven het gedrag van het systeem weer vanuit het gezichtspunt van de gebruiker en gaan over de functionaliteit van het systeem, niet over hoe het systeem dat moet doen. Het levert waarneembaar resultaat op voor de gebruiker, is doelgericht en wordt gemodelleerd en beschreven in een functionaliteitendiagram en tekst (use-case diagram). Syntax van het functionaliteiten diagram: systeem: de te realiseren functionaliteit actoren: externe eenheden die met het systeem communiceren functionaliteit (use-case): de doelmatigheid zoals gezien door de gebruiker relaties: relaties tussen actoren en functionaliteiten (use-cases) en functionaliteiten onderling.
Activiteitendiagram (cel 15) Beschrijving Het activiteitendiagram (activity diagram) omvat de activiteitenanalyse. Dit is een analyse die het tijdsgerelateerde gedrag binnen een functionaliteit (use-case) beschrijft en in kaart brengt. Het is een in feite een decompositie van een functionaliteit in stappen. De systeemfuncties van de gekozen IT-oplossing worden sequentieel of parallel en synchroon of asynchroon gerelateerd aan de activiteitenstappen. In de
activiteitenanalyse kan je ook aanduiden welke stappen wel of niet geautomatiseerd worden. De activiteitenanalyse omvat verschillende scenario’s binnen een functionaliteit (use-case). Elk scenario wordt in een afzonderlijk "Sequentie Diagram" behandeld. De sequentiële relaties die de interactie stuurt tussen de actoren en het systeem, kunnen uit de activiteitenanalyse gedefinieerd en gebruikt worden in het sequentie diagram.
Gebruikersinterface - maquettes (navigatie, menu en scherm) (cel 16) Beschrijving Op basis van de eisen en wensen van de klant wordt een ontwerp of maquette van de gebruikersinterface opgesteld van de toepassing. In het ontwerp wordt de gewenste functionaliteit van de toepassing gestructureerd beschreven (dit is een nadere detaillering van de functionele beschrijving ). In het ontwerp van de gebruikersinterface wordt vastgelegd hoe de functionaliteit wordt gepresenteerd aan de gebruiker. Het ontwerp worden nauwgezet met de gebruiker afgestemd, zodat de kans op onjuiste interpretaties en valse verwachtingen tot een minimum wordt beperkt.
Logisch data /klasse diagram - datamodel (klassen en objecten) (cel 17) Beschrijving Een klassendiagram (class diagram) legt vast welke klassen (objecttypen) er in het systeem voorkomen, wat hun attributen en operaties zijn, en welke statische relaties tussen de klassen bestaan. Statische relaties tussen klassen vallen uiteen in associaties: de ene klasse maakt gebruik van de diensten van de andere, generalisaties: de ene klasse is een subtype van de andere, d.w.z. objecten van de ene klasse kunnen zonder bezwaar worden opgevat als objecten van de andere (dynamische relaties tussen klassen, bijvoorbeeld de volgorde waarin zij berichten uitwisselen, worden in het klassendiagram niet getoond). aggregaties: de ene klasse is een onderdeel van een andere klasse. Een object diagram daarentegen illustreert een klassendiagram door concrete objecten (instanties van klassen) en hun eigenschappen en relaties te tonen.
Logische architectuur informatiesysteem - wat en waar (cel 18)
Beschrijving De logische architectuur beschrijft wat de informatiestromen zijn en waar de fysische communicatieverbindingen zich situeren t.o.v. de voorheen in kaart gebrachte locaties, rekening houdend met de technische noden van bv. de “concurrent users” en andere. Hierbij wordt de nadruk gelegd op de invulling van de gebruikersbehoeften die ingevuld kunnen worden door beslissingen over soort hardwareplatformen, netwerken, ...
Technische Diagrammen (Ontwerp) (cellen 19 t.e.m. 24) Doel: Vertaling van IT-gerichte analyse naar technische concepten rekening houdend met de verschillende focussen (gekozen hardware, gebruikers, databanken, opsplitsing van het systeem, ...). Basis voor constructie Essentiële documentatie voor installatie, exploitatie en onderhoud. Resultaat: Voor de ontwikkelaar bruikbare documentatie conform vereisten van de klant.
Toestandsdiagram - componenten waarop bedrijfsregels ageren (cel 19) Beschrijving Een toestandsdiagram (statechartdiagram) beschrijft de volgorde van toestanden die een object doormaakt in zijn levenscyclus in relatie tot gebeurtenissen in de omgeving van het object, samen met zijn reacties en acties. Het diagram is een graaf bestaande uit toestanden en toestandsovergangen behorende bij objecten van een bepaalde klasse in het algemeen, of bij de gedetailleerde specificatie van een methode uit een bepaalde klasse in termen van subtoestanden, acties en gebeurtenissen in het bijzonder. In principe kan de ‘dialoog’ tussen mens en machine volledig worden gespecificeerd in de vorm van een toestandsdiagram (of STD; een term die het essentieel dynamische aspect van zo’n schema beter weergeeft). Een toestandsdiagram laat zich weergeven als blokjes die staan voor interfacetoestanden (met daarin de naam van de betreffende toestand), verbonden door pijlen die staan voor toestandsovergangen. Zulke overgangen worden veroorzaakt door de handelingen van gebruikers en het systeem. Volgens een gangbare conventie dient bij elke pijl te worden vermeld welke gebruikers- of systeemhandeling tot de betreffende overgang leidt, en onder welke voorwaarden die handelingen dat effect hebben, eventueel aangevuld met acties en gevolgen anders dan de toestandsovergang. Dergelijke diagrammen zijn heel geschikt om bedrijfsregels te concretiseren naar IT analyse en ontwerp, waardoor de implementatie ervan gemakkelijker gecontroleerd kan worden.
Interactiediagram (cel 20) Beschrijving
Interactiediagrammen (collaboration diagrams) kunnen gebruikt worden om de interactie/communicatie tussen samenwerkende objecten weer te geven (berichten, volgorde van de berichten, relaties tussen objecten), een vergelijkbare functie dus als die van sequentiediagrammen. Daar waar in een sequentiediagram echter de nadruk ligt op de volgorde en het tijdsverloop van de tussen objecten uitgewisselde berichten, benadrukt een interactiediagram vooral de relaties tussen de samenwerkende objecten. Het wordt gebruikt om inzicht te krijgen in het gedrag van systeem, het illustreren van de functionaliteiten (use-cases) en het controleren van toegangspaden met nadruk op links tussen objecten.
Sequentie-diagram /volgorde in tijd / communicatie tussen objecten (cel 21) Beschrijving Het sequentiediagram (sequence diagram) toont de volgorde in tijd van de boodschappen/berichten die in het systeem verstuurd en ontvangen worden en beschrijft de communicatie tussen de objecten. Dit diagram toont hoe de objecten samenwerken om een doel te bereiken. Het sequentie-/activiteitenstappendiagram wordt gebruikt voor: inzicht in gedrag van systeem beschrijving van scenario van functionaliteiten (use-cases) controle van “toegangspaden”.
Gebruikersinterface - grafisch ontwerp/technische beschrijving (cel 22) Beschrijving Onderdelen van de gebruikersinterface zijn bijvoorbeeld de schermlayout, de manier waarop de cursor wordt verplaatst over het scherm, het gebruik van de muis en de helpfunctie. Er wordt over het algemeen onderscheid gemaakt tussen GUI (een grafische gebruikersinterface) en een CUI (een gebruikersinterface gebaseerd op cijfers, letters en symbolen). Bij de grafische gebruikersinterface communiceert de gebruiker met behulp van de muis en pictogrammen waarop kan worden geklikt. In het technische ontwerp worden de gebruikerseisen t.o.v. de gebruikersinterface uitgewerkt en gedetailleerd. Waar in de logische diagrammen de nadruk ligt op wat de gebruiker via de maquettes aangeboden krijgt, ligt de focus in de technische diagrammen op welke manier de informatie opgehaald, weggeschreven en gevalideerd wordt. Bv.: het delen van resources is kenmerkend voor client/server; zo maken meerdere clients gebruik van de diensten van dezelfde databaseserver. Wanneer meerdere personen een voorwerp gezamenlijk willen gebruiken, dan houdt dat in dat op één bepaald tijdstip één van de personen de beschikking over het voorwerp heeft en dat de andere personen moeten wachten tot de tijdelijke eigenaar het voorwerp vrij geeft. Als de tijdelijke
eigenaar het voorwerp niet meer vrij geeft, kan dat problemen opleveren voor de anderen. Dit gaat ook op voor clients en servers. Daarom moet er vastgesteld worden welke resources door de verschillende clients gedeeld zullen worden (gebruikers perspectief), en moet gemeenschappelijk gebruik gecontroleerd worden (technisch perspectief).
Technische data diagram (ERD) Persistente data-laag (cel 23) Beschrijving In het technische ontwerp worden de functionele eisen uitgewerkt en gedetailleerd. Het logisch ontwerp in de bovenliggende cel is een vereenvoudigd, platform-onafhankelijk model vanuit het perspectief van de gebruiker. Je zou het ontwerp kunnen implementeren en het werkt, zij het mogelijk wat traag. Om die reden wordt het logisch datadiagram enerzijds vertaald naar een Technisch data diagram en een ERD schema (fysisch data model). Technische optimalisatie (fysisch databank ontwerp) concentreert zich op: efficiency: techische optimalisatie zorgt ervoor dat de belangrijkste functies een goede performance hebben. eenvoud: een volledig logisch model kan lastig zijn om mee te werken. SQL queries kunnen bijvoorbeeld ingewikkeld worden op een volledig logische database. Daarnaast wordt het logisch data diagram verder verfijnd naar een technisch data diagram waarbij objecten gegroepeerd worden in subsystemen, keuzes gemaakt worden rond patterns en frameworks, ... Het logisch ontwerp was vooral geleid door regels. Bij technische optimalisatie komt het meer aan op creativiteit, inventiviteit en technisch vernuft, waarbij de gekozen technische architectuur mede bepalend zal zijn bij de technische verfijning.
Technische architectuur informatiesysteem (hw, sw, data, net) (cel 24) Beschrijving In een technische architectuur informatiesysteemdiagram wordt de runtime structuur van een software-systeem weergegeven. Hierbij bestaat het systeem uit nodes, fysieke objecten die in staat zijn bewerkingen uit te voeren, componenten en objecten. Alleen de componenten die tijdens runtime van belang zijn worden hierbij weergegeven. Een node beschikt meestal over geheugen en rekenkracht en kan zowel een computer, een menselijke uitvoerder, als een andere mechanische bron voorstellen. Een node kan zowel in type- als instantievorm voorkomen en wordt weergegeven als een driedimensionale rechthoek. In of onder de rechthoek wordt het type, en optioneel de naam van de instantie weergegeven. In een node kunnen componenten en objecten zijn weergegeven; dit betekent dat deze entiteiten zich tijdens runtime op de betreffende node kunnen bevinden. Indien een entiteit kan worden verplaatst naar een andere node wordt dat aangegeven met een onderbroken pijl met stereotype «becomes» tussen instanties van de entiteit in de eerste en de tweede node.
Ook een component kan objecten bevatten; deze objecten maken deel uit van de component en worden in de component weergegeven. Deze compositierelatie kan eventueel ook met een compositieassociatie worden weergegeven. Tevens is het mogelijk hiertoe een location attribuut in het object op te nemen dat naar de omvattende component verwijst. Deze notatievormen voor compositierelaties zijn ook geldig voor een node. Een afhankelijkheidsrelatie van het stereotype «supports» geeft aan welke componenten zich op welke nodes kunnen bevinden. Communicatie tussen nodes wordt weergegeven door een lijn tussen nodes. Hierbij kan een naam bij de lijn aangeven wat voor soort communicatie er plaats vindt. Een component is een tastbaar stuk van een implementatie van een systeem. Dit kunnen software-componenten zijn die tijdens compile(broncode), link- (objectcode) of runtime (machinecode) van belang zijn, maar het kunnen ook andersoortige documenten zijn die bij een systeem bestaan. Deze componenten kunnen afhankelijk zijn van elkaar, net als klassen of objecten afhankelijk kunnen zijn van elkaar. In een componentdiagram worden de componenten en hun afhankelijkheden inzichtelijk gemaakt. Een component wordt hierbij weergegeven als een rechthoek met aan de linkerkant twee uitstekende rechthoekjes; in of onder het component wordt het type weergegeven. In het componentdiagram komen alleen componenttypen voor, de uiteindelijke componentinstanties zien we terug in het deploymentdiagram. Dit onderscheid tussen type en instantie volgt de standaard type/instantie-notatie. De afhankelijkheden tussen componenten worden weergegeven met onderbroken pijlen. Deze pijlen kunnen ook naar eventuele interfaces van een component wijzen. Indien een component deel uit maakt van een andere component dan wordt deze in de bevattende component weergegeven.
Constructie Diagrammen (Bouw) ( cellen 25 t.e.m. 30) Doel: De IT-applicatie (als module van IT-informatiesysteem) ontwikkelen. Duidelijke documentatie genereren over het IT-project (programma documentatie, broncode, schermen, DB-documentatie e.d.) zodat installatie, adaptief en correctief onderhoud en eventuele overname vlot verloopt. Resultaat: Voor technici bruikbare documentatie conform vereisten van de klant.
Programmadocumentatie (cel 25) Beschrijving In deze cel wordt de documentatie bij de programmatie ondergebracht. Hiertoe behoren: de documentatie van de logica van het programma, de keuzes die bij de programmatie gemaakt werden; de documentatie die het gebruik (o.a. de publieke interface) van de verschillende onderdelen van het programma beschrijft. De programmatie documentatie kan in een afzonderlijk document opgenomen worden of kan bij in de broncode (“inline”) geplaatst worden.
Programma Code conform bedrijfsregels (cel 26) Beschrijving De vorm van de broncode is afhankelijk van de gekozen technologie en taal.
Integratie globaal (logica, DBMS, GUI, hw, sw, net) + opmaak testplan (cel 27) Beschrijving De integratie van alle gedefinieerde elementen zoals hardware, software, gebruikersinterface, enz. en het opmaken van het acceptatietestplan.
Programmatie Schermen (pagina's, menu, velden, knoppen) (cel 28) Beschrijving De vorm waarin gebruikersinterface wordt ontwikkeld, is afhankelijk van de gekozen taal en technologie. De gebruikersinterface bestaat typisch uit de specifieke designer-bestanden van de gebruikte ontwikkelingsomgeving. Voorbeelden zijn: Formulieren in MS Access, Visual Basic .FRM bestanden, VC++/MFC resources en CForm classes, …
Programmatie databank en I/O-bewerkingen (creatie, read, write, delete, rollback,..) (cel 29) Beschrijving Tot de broncode databank behoren de SQL DDL statements voor het aanmaken van de RDBMS. De DDL statements (CREATE TABLE, INDEX,….) vormen de vertaling van het Technisch data diagram in instructies voor de aanmaak van de databank. De DDL-statements worden typisch onder de vorm van een ASCII-tekstbestand aangemaakt (een .SQL bestand). Naast de broncode voor de aanmaak van de databank behoren tot deze cel ook de broncode voor de manipulatie van de gegevens in de databank (INSERT, SELECT, UPDATE, DELETE, …). De vorm van deze databankmanipulatie-instructies is afhankelijk van de gekozen technologie en ontwikkelingstaal. Voor de programmatie van de databank wordt bijvoorbeeld gebruik gemaakt van: Query’s en VBA broncode in MS-Access, Visual Basic of VC++ broncode die gebruik maakt van ODBC, ESQL/C broncode bestanden, …
Fysische architectuur informatiesysteem (hw, sw, data,net) (cel 30) Beschrijving Onder deze noemer wordt de concrete fysische architectuur van het informatiesysteem aangegeven. Onderdelen hiervan kunnen zijn: de fysische servers, de locatie van de servers, de software componenten geïnstalleerd op elk van deze servers, de datastorage voorzieningen op de servers, de fysische netwerktopologie, de PC’s gebruikt door de gebruikers, de software op de PC’s, ... De fysische architectuur van het informatiesysteem wordt typisch aangegeven onder de vorm van schema’s met de fysische servers, de locaties, ...
Testen (cellen 31 t.e.m. 33) Doel: Ontwikkelde applicaties en bijhorende procedures testen vanuit alle invalshoeken zodat kwaliteit gegarandeerd wordt. Onontbeerlijk bij acceptatie van een applicatie. Resultaat: Testverslagen: doel, testprocedure en resultaten die door klant en leverancier aanvaard worden.
Validatie vertaalde bedrijfsregels (cel 31) Beschrijving Onder de validatie van de vertaalde bedrijfsregels worden gerichte testen verstaan die de correcte implementatie van de bedrijfsregels (of van een subset van de bedrijfsregels) nagaan. Voor complexe bedrijfsregels worden de testen opgebouwd volgens een “bottom-up” mechanisme: eerst wordt het correct functioneren van de afzonderlijke elementaire bedrijfsregels gecontroleerd daarna wordt de samenhang en interactie tussen de elementaire bedrijfsregels getest. Een afzonderlijke reeks testen kan gewijd worden aan “boundary testen”: controle dat de mimimum en maximum waarden, de grenzen gesteld in de bedrijfsregels correct geïmplementeerd worden (bv. dat er een correcte foutboodschap gegeven wordt bij overschrijden van een grens). Om een maximale “code coverage” te verkrijgen kunnen deze testen opgesteld worden volgens een “white-box” principe waarbij er aan de hand van de broncode wordt nagekeken of de voorgestelde testen de verschillende situaties en uitzonderingen omvatten.
Centrale en remote testen informatiesysteem (cel 32) Beschrijving In het algemeen worden de testenscenario’s opgezet vanuit het oogpunt van de eindgebruiker en de wijze waarop hij het systeem in de praktijk zal gebruiken. De testscenario’s kunnen dan ook volgen uit de use cases. Deze testscenario’s volgens het “black-box” testingprincipe: zonder kennis of rekening te houden met de interne werking van het systeem. Voor systemen die uit meerdere complexe onderdelen bestaan wordt er een onderscheid gemaakt tussen het testen van elk van de onderdelen en het testen van het geïntegreerde geheel.
Naast de functionele testen kan een belangrijk onderdeel van de testen het testen van de beveiliging inhouden. Hiervoor kunnen gespecialiseerde testen voorzien worden. Een ander standaardonderdeel van de testen vormen de stress-testen. Hierbij wordt het gedrag van de software of het systeem nagegaan aan of voorbij de limieten van de vooropgestelde specificaties. Bij een additieve ontwikkeling kan een afzonderlijke reeks “regressietesten” voorzien worden: niet alleen worden de nieuw toegevoegde functies getest maar ook de reeds bestaande functies worden opnieuw getest. Dit om te controleren dat de nieuwe ontwikkelingen geen onbedoelde effecten heeft op de reeds bestaande onderdelen. Testen kunnen manueel uitgevoerd worden of met gebruik van een automatische testtool. De test-scripts om automatisch een bepaalde batterij van testen op de ontwikkelde toepassing uit te voeren, zijn een bijkomend resultaat van deze cel. In deze cel vindt men terug: beschrijving van de testen, logboek van de testen, verslag van de resultaten van de uitgevoerde testen, testgegevens noodzakelijk voor het uitvoeren van de testen.
Testen transitie (cel 33) Beschrijving Onder deze noemer worden alle activiteiten ondergebracht die nodig zijn om de transitie van een bestaande toepassing of andere bestaande situatie naar de nieuwe situatie uit te testen. Hiertoe behoren: draaiboeken voor het voorbereiden van de transitie, opzetten van een kopie van het systeem voor het uittesten van de transitie (“dry run” van de “go live” van het project). Hierbij horen ook de analyse van de structuur van de bestaande data en de mapping naar de nieuwe structuur; de opmaak van hulpmodules voor het omzetten van bestaande gegevens naar de nieuwe databankstructuur; het maken van rapporten met inconsistente gegevens zoals dubbele gegevens, ontbrekende gegevens, fout geformatteerde gegevens, ... Het testen van de transitie kan naast het eigenlijke informatiesysteem ook betrekking hebben op externe systemen waarmee gecommuniceerd worden, heroriëntering van resources, ...
Uitrol (cellen 34 t.e.m. 39) Doel: Validatie van de (nieuwe of gewijzigde) applicatie: formele acceptatie, installatie, beheer, ondersteuning, ... van het systeem. Organisatorisch in gebruik nemen van de applicatie: opleidingen, infosessies e.d. Resultaat: Goede en betrouwbare en degelijk gebruikte en beheerde applicatie.
Acceptatie (cel 34) Beschrijving In deze cel worden de gegevens behorend tot de acceptatie ondergebracht. De acceptatie bestaat uit een reeks van formele testen die uitgevoerd worden om te bepalen of het ontwikkelde systeem voldoet aan de acceptatiecriteria. De acceptatie, op basis van business scenario’s, moet de klant toe laten te beslissen of hij al dan niet het ontwikkelde systeem kan accepteren. Tot de acceptatie behoren de resultaten van de uitgevoerde acceptatietesten.
Opmaak handleidingen beheerders, helpdesk en gebruikers (cel 35) Beschrijving Onder deze noemer worden geplaatst: de handleidingen voor de gebruikers, de beheerders, helpdesk, voor de installatie, ... Handleidingen zijn typisch onder de vorm van MS-Word bestanden, maar kunnen ook online zijn, onder de vorm van HTML-bestanden. Andere mogelijke vormen van on line helpbestanden .HLP voor de MS-Windows platformen, bestanden in PDF-formaat, ...
Installatie informatie-systeem (hw, sw, data,net) (cel 36) Beschrijving In deze cel vindt men de gegevens van het installatieproces terug: exploitatiedossier, installatiehandleidingen, de bestanden nodig voor de installatie van het informatiesysteem (onder de vorm van setup-programma’s, PKG-packages, tar-bestanden, ...).
Opleiding beheerders, helpdesk en gebruikers (cel 37) Beschrijving Typisch wordt er een gespecialiseerde opleiding voorzien voor de verschillende rollen of types van gebruikers die voor het informatiesysteem van belang zijn. Materiaal voor opleiding kan bestaan uit: cursus, oefeningen, PowerPoint-samenvatting van de behandelde onderdelen.
Setup, migratie, conversie van data (cel 38) Beschrijving In deze cel worden de gegevens voor de uitvoer van de migratie en conversie samengebracht. Hiertoe behoren de verslagen met de resultaten van de converies: ontbrekende gegevens, conflicterende gegevens, ...
Go Live met beheer en exploitatie en helpdesk infosysteem (cel 39) Beschrijving Men vindt in deze cel een logboek of ander mechanisme terug voor het registreren en opvolgen van meldingen i.v.m. het in productie genomen systeem (meldingen van fouten, vragen voor wijzigingen, extra functies,...). Voor toepassingen waarbij er een client-installatie noodzakelijk is, is er specifieke documentatie die te gebruiken is voor de installatie van een bijkomende client. Voor sommige projecten kan hierbij specifieke documenten opgemaakt worden voor de ondersteuning van de helpdesk.
