Implementeren van computersystemen

Status: in ontwikkeling

Dit hoofdstuk gaat over implementeren van (eenvoudige) informatiesystemen. Implementeren is zorgen dat gebruikers werken met dat systeem. Doel van deze tekst is systeembeheerders een leidraad geven voor het uitvoeren van een implementatieproject.

Inleiding

Ontwikkeling van een informatiesysteem gaat vaak in de volgorde:

• Idee
• Definitie
• Ontwerp
• Bouw
• Implementatie
• Gebruik en beheer

Een informatiesysteem kan van alles zijn, bijvoorbeeld:

• een website
• een firewall
• een “van scratch af aan” gebouwd programma
• een gekocht softwarepakket

Op een bepaalde datum, de "go-live" datum wordt het systeem in productie 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.

Lege pagina, hoe kan ik deze renamen ? Knopje "wijzig titel" van Help:Titel van een artikel wijzigen zie ik niet.

Los-vaste 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 test– en productieomgeving(en)
4. Inrichten versiebeheer
5. Uitvoeren van metingen t.b.v. planning
6. Conversie van gegevens

Schaduwdraaien of “Big Bang”

Er zijn twee manieren 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.

Schaduwdraaien: het oude en nieuwe systeem draaien enige tijd naast elkaar, weken tot maanden. In die schaduwperiode wordt op beide systemen productie gedraaid. 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

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.

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)

Het is bij systeemontwikkeling belangrijk om de beschikking te hebben over de drie genoemde soorten systemen. Dit voorkomt ernstige storingen, onnodig gegevensverlies en doo elkaar lopen van activiteiten. In veel gevallen moeten deze systemen nog worden gebouwd in de volgorde organiseren, aanschaffen, installeren etc.

Versiebeheer

Alle informatiesystemen worden gebouwd in versies. Een nieuwe versie is een verbeterde versie van de oude. Versies kunnen zijn aangepaste sources, aangepaste instellingen etc. 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 procedureel dan een technisch probleem.

Metingen t.b.v. planning

Bij bepaalde activiteiten zie je aankomen dat deze veel tijd vragen, bijvoorbeeld het overtypen van gegevens. Om een schatting te kunnen maken van de benodigde tijd is het handig om in de voorbereiding op kleine schaal 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 het overtypen van 20 facturen tijdens een meting éé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 productiesysteem 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.

Conversie 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 door veroudering)

Er zijn drie soorten conversies:

1. Eenvoudig: de gegevens veranderen niet van waarde, structuur of volgorde. 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, structuur of volgorde. 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 wel van waarde, structuur of volgorde. Hiervoor is complexe conversieprogrammatuur nodig. Deze programmatuur leest regel voor regel een inputfile, voert bewerkingen uit en schrijft een outputfile. Bewerkingen kunnen eenvoudig, gemiddeld of uitgebreid zijn.

Voorbeelden van conversies
	Oude record	Nieuwe record
Waarde	“3012AL”	“3012 AL”
Structuur	aantal, prijs	aantal, prijs, regeltotaal
Volgorde	Factuurnummer, x keer (aantal, prijs), factuurtotaal	Factuurnummer, factuurtotaal, x keer (aantal, prijs)