Implementeren van informatiesystemen

Implementeren is zorgen dat gebruikers gaan werken met een informatiesysteem, bijvoorbeeld een webwinkel. Dit hoofdstuk gaat over implementeren van (eenvoudige) informatiesystemen. Het doel van deze tekst is een leidraad geven voor het uitvoeren van een implementatieproject.

Inleiding

Een informatiesysteem kan van alles zijn, bijvoorbeeld:

• een website of webwinkel
• een voorraadsysteem
• een helpdesksysteem
• een nieuw gebouwd (“van scratch af aan”) programma

Ontwikkelen van een informatiesysteem gaat vaak in de volgorde:

• Idee: iemand wil iets of er moet een probleem worden opgelost.
• Definitie: het idee wordt onderzocht en uitgewerkt, heet ook wel analyse
• Ontwerp: het nieuwe systeem wordt op papier beschreven.
• Bouw: het systeem wordt gemaakt: o.a. hard- en software; procedures en opleidingen.
• Implementatie: het systeem wordt in produktie genomen, gebruikers gaan er mee werken.
• Gebruik en beheer: het systeem is in produktie en levert de informatie waar het voor is. Het wordt dagelijks onderhouden: storingen oplossen en wijzigingen aanbrengen.

Op een bepaalde datum, de "go-live" datum wordt het systeem in produktie genomen. Implementeren is de overgang van “het werkt bij de programmeur” naar “het werkt bij gebruikers”. Implementeren is een vak apart en wordt vaak uitgevoerd door een specialist, een implementeerder. Bij implementeren ligt de nadruk meer op organiseren dan op techniek.

Primaire activiteiten

Implementeren heeft de volgende primaire ("belangrijkste") activiteiten:

1. Organiseren van alle activiteiten
2. Plannen van het geheel zodanig dat op een bepaalde datum “live” kan worden gegaan
3. Testen in diverse vormen
4. Completeren van systeem– en gebruikersdocumentatie
5. Motiveren van gebruikers
6. Het productiesysteem vullen met startgegevens
7. Begeleiden van opstarten en kinderziekten

Organiseren

Onder organiseren valt:

• Activiteiten juist en compleet benoemen
• Activiteiten koppelen aan (groepen) medewerkers
• Medewerkers instrueren en motiveren
• Materialen regelen

Plannen

Plannen is activiteiten uitzetten in de toekomst zodanig dat je naar een “go-live” datum toewerkt. Een planning gaat over weken tot maanden. Het is nodig omdat de opdrachtgever wil weten wanneer zijn organisatie kan werken. Tijdens het uitvoeren van de planning hou je toezicht op de activiteiten. Waar nodig stuur je bij en informeer je de opdrachtgever. Een planning halen is niet eenvoudig maar wel belangrijk.
"Je zult een planning vaak niet halen maar je ziet wel dat je afwijkt."
"Je kan niet alles voorzien maar je kan wel zorgen dat je het meeste voorziet."
"Zonder planning heb je geen enkele leidraad."

Testen in diverse vormen

Testen is controleren of het systeem doet wat is beloofd. Primair zijn de bouwers verantwoordelijk voor unittest en systeemtest. In de praktijk speelt de implementeerder een grote rol bij testen zodat hij/zij op deze manier goed inzicht krijgt in de werking van het systeem. Dit is belangrijk omdat de implementeerder door gebruikers vaak aanspreekpunt is voor kinderziekten.

Er bestaan de volgende technische testen:

• Unittest: testen van de kleinst testbare eenheid, bijvoorbeeld een losse softwaremodule of een menukeuze die verschillende modules aanroept.
• Systeemtest: testen van alle testbare eenheden in samenhang met elkaar.
• Stresstest: het systeem onder druk zetten: veel invoer, veel gebruikers, beperking in verwerkingsmogelijkheden.

Het resultaat van deze testen is dat de software technisch werkt. Er zijn geen errors meer, de software stopt er niet plotseling mee, de snelheid (performance) is voldoende . De fouten waaraan is gedacht (!) zijn getest en ze worden door de software goed opgelost.

Er bestaan de volgende gebruikerstesten:

• Functionele test: werkt het systeem of onderdeel zoals het is ontworpen.
• Acceptatietest: aanvaarden de gebruikers het systeem gelet op de functies en performance.

Wat vaak niet gedaan wordt, waarschijnlijk omdat het geen enkele duidelijke omschrijving heeft, is de test om na te gaan dat 'verkeerd' gebruik, of foute data, geen invloed heeft.

Ook basis-gebruiksvriendelijkheid zou moeten getest worden: (bijv. wanneer een emailadres gevraagd wordt, dan zou het niets mogen uitmaken of de gebruiker er een spatie voor of achter tikt. Toch hebben de meeste websites hier een probleem mee, inclusief de Apples en Microsofts van deze wereld! )

Het resultaat van deze testen is dat de gebruikers akkoord gaan met de software zoals die op dat moment werkt. Als men wil dat de software anders werkt moet het ontwerp opnieuw worden herzien.

Completeren van systeem– en gebruikersdocumentatie

Als het systeem in productie is moeten gebruikers en technische medewerkers antwoorden kunnen opzoeken. De gebruikelijke valkuil is dat gebruikersdocumentatie half en te laat af is en systeemdocumentatie nauwelijks wordt gemaakt. De kennis zit vaak in de hoofden van de medewerkers, dat is een risico bij calamiteiten.

Motiveren van gebruikers

Een systeem werkt pas goed als het door de meeste gebruikers wordt geaccepteerd. Dat kun je bereiken door o.a. cursussen, nette documentatie, problemen en wensen verwerken en kleine feestjes. Veel gebruikers zitten niet te wachten op een nieuw of aangepast systeem (“het ging toch goed, waarom anders”). Mensen goed laten werken met een systeem duurt daarom heel lang. De hoofdverantwoordelijke voor acceptatie is het management van de organisatie, in de praktijk ligt er een zware rol bij de implementeerder.

Het produktiesysteem vullen met startgegevens

Tijdens de bouw wordt een systeem getest met testgegevens. Vanaf de go-live datum moet het systeem gevuld zijn met de gegevens van de dag daarvoor. Deze gegevens zijn de enige die overeenstemmen met de werkelijkheid. Als de gegevens niet up-to-date zijn wordt ieder probleem en iedere kinderziekte uitvergroot en vermindert de acceptatie van een systeem. 99% juist bestaat hier niet.

Begeleiden van opstarten en kinderziekten

De eerste weken na de go-live zijn kritisch. Tijdens het eerste gebruik komen problemen aan het licht die zo snel mogelijk moeten worden opgelost. Ondanks zware testen heeft ieder systeem problemen die niemand heeft voorzien. Gebruikers accepteren een zekere hoeveelheid tegenslagen (“kon de hele ochtend niet werken”) mits die snel en zichtbaar (!) worden opgelost.

Secundaire onderwerpen

De volgende los-vaste onderwerpen zijn bij implementeren van belang:

1. Keuze voor schaduwdraaien of “Big Bang”
2. Draaiboek “go-live” maken
3. Inrichten van ontwikkel-, test– en produktieomgeving
4. Inrichten versiebeheer
5. Uitvoeren van metingen t.b.v. planning
6. Conversie van gegevens

Schaduwdraaien of “Big Bang”

Er zijn twee uitersten om een nieuw systeem in productie te nemen:

• Big Bang: het oude systeem wordt in zeer korte tijd, bijvoorbeeld een dag of weekend, vervangen door het nieuwe. Het nieuwe systeem gaat direct in productie en het oude systeem wordt gestopt.

• Schaduwdraaien: het oude en nieuwe systeem draaien enige tijd naast elkaar, weken tot maanden. In die schaduwperiode wordt op beide systemen productie gedraaid.

Tussen deze uitersten zijn er vele tussenvormen denkbaar. Bij een gefaseerde overgang wordt het nieuwe systeem stukje bij beetje in gebruik genomen, ieder stukje kan met een Big Bang. Let op: het “oude systeem” is niet altijd een computer maar kan ook een handmatige werkwijze zijn.

Big Bang en schaduwdraaien
	Voordelen	Nadelen
Big Bang	Minder kosten	Gevolgen van verstoringen door kinderziekten ernstig
	Eén manier van werken
Schaduwdraaien	Gevolgen van verstoringen door kinderziekten beperkt	Hogere kosten door dubbel werk
		Risico van niet-synchroon lopen van oude en nieuwe systeem

Draaiboek “go-live”

Een draaiboek is een detailplanning voor één of twee dagen. Een planning is tot op de dag nauwkeurig, een draaiboek is op de minuut nauwkeurig. Draaiboeken worden gemaakt voor situaties waar in korte tijd veel werk moet gebeuren waarvan de uitvoering heel kritisch is, bijvoorbeeld een wedstrijdschema van een ééndaags sporttoernooi. Implementeerders maken bijvoorbeeld een draaiboek voor een “go-live” waarbij het oude systeem op vrijdag wordt afgesloten, gegevens worden overgezet en het nieuwe systeem op maandag in de lucht gaat.

Inrichten van ontwikkel–, test– en productieomgeving(en)

Een "omgeving" is de hard- en software die de ontwikkelaars gebruiken om het systeem te bouwen.

Er zijn minimaal drie soorten omgevingen:

• in een ontwikkelomgeving maken de programmeurs de software. Het eindresultaat is dat die software technisch werkt, er zijn geen run-time errors of andere fouten meer. Deze software kan worden klaargezet voor testen.
• in een testomgeving testen de testers de software. Het eindresultaat is dat die software technisch en functioneel is goedgekeurd: het doet waarvoor het is ontworpen. Deze software kan worden klaargezet voor productie.
• in een productieomgeving is het systeem in productie: de informatie die in en uit gaat komt overeen met de werkelijkheid. De gegevens die in het systeem zijn opgeslagen zijn belangrijker dan het systeem zelf. De productieomgeving moet 99,9% van de tijd werken ("in de lucht zijn").

Naast deze drie omgevingen bestaat er soms een acceptatieomgeving: hierop testen de gebruikers het systeem namens de opdrachtgever. Het eindresultaat is dat die software technisch en functioneel is goedgekeurd. Deze software kan worden klaargezet voor productie.

Soorten omgevingen
	Ontwikkelomgeving	Testomgeving	Productieomgeving
Verantwoordelijke	Programmeur	Tester	Systeembeheerder
Gemiddelde hardware	PC	Meerdere (zware) PC's in netwerk	Server, mini of mainframe
Software	Editors, compiler, library's, sources	executable software	executable software, software voor systeembeheer
Soorten testen	Unittest	Systeemtest, Stresstest, Functionele test, Acceptatietest	Dagelijkse controle
Gegevens	Complete set, kleine hoeveelheid	Complete set, grote hoeveelheid	Werkelijkheid
Versie	Nieuwe versie Versiebeheer van oude versies	Kopie van productieomgeving	productieversie
Overig		Hardware soms backup voor productieomgeving Gebruikt voor debuggen en reproduceren van storingen

Er moeten goede spelregels zijn om deze systemen gescheiden te houden. Als ontwikkel-, test- en productieversies door elkaar gaan lopen ontstaat er een groot risico van productiestoringen die niet (snel) worden opgelost. Het is daarom belangrijk om de beschikking te hebben over deze drie soorten omgevingen. In veel gevallen moeten tijdens de implementatie deze nog worden gebouwd of verbeterd. Dit moet worden georganiseerd en er is doorlooptijd voor organiseren, aanschaffen, installeren etc.

Versiebeheer

Alle informatiesystemen worden gebouwd in versies. Een versie is het geheel van software (aangepaste sources, aangepaste instellingen etc.) van een bepaalde datum en tijd. Een nieuwe versie is een verbeterde versie van de oude. Veel voorkomende valkuilen zijn: “in de vorige versie werkte het nog” “in deze versie werkt functie A wel maar functie B niet meer” Het is vervelend als de vorige versie er niet meer is, dit bemoeilijkt en vertraagt het uitzoeken. Het is daarom belangrijk alle versies goed te bewaren in een versiehistorie. Bij goed versiebeheer kun je altijd terug naar een werkende situatie.

Het maken van een eenvoudige versiehistorie gaat als volgt:

Stap 1: Stel vast wat je onder een versie verstaat.

Dit kan zijn een programmamodule, een heel systeem, een hele directory, een geheel van instellingen etc. Zorg dat de relevante onderdelen van een versie, bijvoorbeeld .bas files, een zinvolle identificatie (=(file)naam) hebben, “module.bas” o.i.d is nietszeggend.

Stap 2: Maak een kopie van de lopende versie.

Een kopie kan zijn een kopie van een directory, kopie(ën) van één of meer file(s), een document met de belangrijke instellingen etc.

Stap 3: Geef deze kopie een zinvolle naam.

Er zijn vele naamgevingen en systemen mogelijk: “\app_21a”, “applicatie_200060201.exe”

Stap 4: Documenteer iedere versie.

Schrijf o.a. naam, module, datum/tijd, verantwoordelijke persoon etc. op in een versielogboek.

Stap 5: Zorg ervoor dat iedereen zich aan deze spelregels houdt.

Versiebeheer is meer een organisatorisch dan een technisch probleem. Het is voor een tester vervelend (...) als de verkeerde versie wordt getest door slordigheid van de programmeur.

Metingen t.b.v. planning

Een meting is kijken hoe lang een bepaalde handeling van een mens of computer duurt. Je meet met een horloge of met de tijdmeting die de software levert. Bij bepaalde activiteiten zie je aankomen dat deze veel tijd vragen, bijvoorbeeld het overtypen van heel veel facturen of het inlezen van een importbestand. Om een schatting te kunnen maken van de benodigde tijd is het nodig om in de voorbereiding metingen te verrichten. Metingen maken de planning en/of draaiboek veel en veel nauwkeuriger.

Voorbeeld 1: bij een implementatie moeten 2000 facturen worden overgetypt. Als tijdens een meting het overtypen van 20 facturen één uur duurt dan zullen 2000 facturen plm. 100 uur duren. Die 100 uur plus wat marge neem je op in de planning.

Voorbeeld 2: een bestand met 2000 facturen moet worden geïmporteerd in een pakket waarbij tijdens het importeren veel controles worden uitgevoerd. Een dergelijke import kan uren duren, afhankelijk van de hardware. Een meting op het produktiesysteem in de vorm van een testimport kan uitwijzen of inlezen 30 minuten of 3 uur duurt. Op een zondagmiddag tijdens een weekendovergang kan dat veel uitmaken.

Converteren van gegevens

Converteren is digitale gegevens van het oude systeem overzetten naar het nieuwe systeem. Converteren gaat sneller en nauwkeuriger dan intypen. Bij bijvoorbeeld een weekendovergang moet het op deze manier omdat anders de gegevens bederven (= onbruikbaar worden door veroudering). Ook informatie op papier overbrengen naar de computer is een vorm van converteren, denk aan scannen of overtypen. Deze vorm van converteren heet digitaliseren.

Er zijn drie soorten digitale conversies:

1. Eenvoudig: de gegevens veranderen niet van waarde, volgorde of structuur. Het oude systeem maakt een exportbestand, bijvoorbeeld een .csv of .txt file en dat is importbestand voor het nieuwe systeem.
2. Gemiddeld: de gegevens veranderen 'een beetje' van waarde, volgorde of structuur. Deze conversie kan met standaard kantoorautomatiseringspakketten. Een exportbestand wordt handmatig bewerkt in een spreadsheet of databasepakket en wordt daarna geïmporteerd in het nieuwe systeem.
3. Complex: de gegevens veranderen uitgebreid van waarde, volgorde of structuur. Hiervoor is complexe conversieprogrammatuur nodig. Deze programmatuur leest regel voor regel een inputfile, voert bewerkingen uit en schrijft een outputfile. De bewerkingen zijn zo complex dat het maken van het conversieprogramma veel ontwikkel- en testtijd kost.

Voorbeelden van converteren
	Oude record	Nieuwe record
Waarde	“3012AL”	“3012 AL”
Volgorde	regel 1: plaats regel 2: straat regel 3: naam	regel 1: naam regel 2: straat regel 3: plaats
Structuur	prijs, aantal	aantal, prijs, regeltotaal