Implementeren van informatiesystemen: verschil tussen versies

Verwijderde inhoud Toegevoegde inhoud
M.vdbeedijk (overleg | bijdragen)
Geen bewerkingssamenvatting
M.vdbeedijk (overleg | bijdragen)
Geen bewerkingssamenvatting
Regel 1:
Status: in ontwikkeling
 
'''Implementeren''' is zorgen dat gebruikers 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 ==
Regel 30 ⟶ 31:
#Het produktiesysteem vullen met startgegevens
#Begeleiden van opstarten en kinderziekten
 
 
=== Organiseren ===
Regel 37 ⟶ 39:
:*Medewerkers instrueren en motiveren
:*Materialen regelen
----<br />
 
=== Plannen ===
Regel 42 ⟶ 45:
"Je zult een planning vaak niet halen maar je ziet wel dat je afwijkt."<br />
"Je kan niet alles voorzien maar je kan wel zorgen dat je het meeste voorziet."
----<br />
 
=== Testen in diverse vormen ===
Regel 57 ⟶ 61:
=== Completeren van systeem– en gebruikersdocumentatie ===
Als het systeem in produktie 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.
----<br />
 
=== 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.
----<br />
 
=== 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.
----<br />
 
=== 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.
----<br />
 
== Secundaire onderwerpen ==
Regel 76 ⟶ 84:
#Uitvoeren van metingen t.b.v. planning
#Conversie van gegevens
 
 
=== Schaduwdraaien of “Big Bang” ===
Regel 110 ⟶ 119:
 
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.
----<br />
 
=== Draaiboek “go-live” ===
Regel 115 ⟶ 125:
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.
----<br />
 
=== Inrichten van ontwikkel–, test– en produktieomgeving(en) ===
Regel 188 ⟶ 199:
 
Er moeten goede spelregels zijn om deze systemen gescheiden te houden. Als ontwikkel-, test- en produktieversies door elkaar gaan lopen ontstaat er een groot risico van produktiestoringen 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.
----<br />
 
=== Versiebeheer ===
Regel 217 ⟶ 229:
 
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.
----<br />
 
=== Metingen t.b.v. planning ===
Regel 225 ⟶ 238:
 
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.
----<br />
 
=== Converteren van gegevens ===
Regel 265 ⟶ 279:
|aantal, prijs, regeltotaal
|}
----<br />
Informatie afkomstig van https://nl.wikibooks.org Wikibooks NL.
Wikibooks NL is onderdeel van de wikimediafoundation.