Aanvullende onderwerpen ISyF

Literatuur C

Aanvullende onderwerpen ISyF

Editie augustus 2014

Copyright©2014 Delemarre, M Alle rechten voorbehouden Niets uit deze uitgave mag worden openbaar gemaakt of verveelvoudigd, opgeslagen in een dataverwerkend systeem of uitgezonden in enige vorm door middel van druk, fotokopie of welke andere vorm dan ook zonder toestemming van M. Delamarre.


2

Colofon Titel:


Auteur:

Marcel Delemarre

Publicatiedatum:

Augustus 2014


3

Inhoudsopgave 1. Mobiele apps ............................................................................................................... 5 2. Agile-softwareontwikkeling .......................................................................................... 7 3. Scrum ........................................................................................................................10 4. RUP ...........................................................................................................................15 5. Functies in de informatievoorziening .........................................................................18 6. Kwaliteit .....................................................................................................................35


4

1. Mobiele apps Een mobiele applicatie of kortweg app is een softwareapplicatie die ontworpen is om te draaien op eens smartphone, tablet of een ander elektronisch handapparaat. Met behulp van apps is het mogelijk eenvoudig extra functies aan een mobiel apparaat toe te voegen, zodat deze kunnen worden uitgebreid tot multifunctionele communicatieapparatuur. De meeste apps worden ontwikkeld voor de platformen Android, Apple IOS en Windows vanaf versie 8. Ze kunnen worden verkregen via appstores. Apps zijn vooral bekend als privétoepassing, bijvoorbeeld voor internetbankieren, amusement, boeken, muziek, routenavigatie, spelletjes en dergelijke. Bedrijven kunnen bepaalde diensten via een app beschikbaar stellen. Een app kan dan worden ingezet om de bestaande dienstverlening van een bedrijf te ondersteunen, maar ook om een merk te versterken. Met zakelijke standaard apps kan de persoonlijke efficiency van medewerkers worden vergroot. Met een smartphone of tablet (met internettoegang) is het mogelijk om onderweg e-mail te beantwoorden, de agenda bij te houden of documenten in te kijken. Er zijn ook standaard apps voor een elektronische agenda, tekstverwerking, spreadsheets, presentaties, aantekeningen maken, brainstormen met mind maps enzovoort. Via push berichten kan een bedrijf haar medewerkers informeren over recente ontwikkelingen. Apps zijn zo krachtig en daardoor zo populair dat smartphones en tablets de PC's en laptops geleidelijk aan verdringen. En daarmee wordt een trend, die met Het Nieuwe Werken (HNW) is ingezet, gefaciliteerd: werk en privé lopen steeds meer door elkaar. Het ultieme Martini-concept: Any Time Any Place, Anywhere! De volgende trend die sinds 2014 hard groeit is die van Business2Employee (B2E): het verpakken van maatwerkapplicaties van organisaties in een app. Daarmee krijgt HNW weer een nieuwe dimensie: werken waar en wanneer je wilt waarbij je zelfs niet meer afhankelijk bent van een pc of laptop. B2E apps worden op maat ontwikkeld voor specifieke bedrijfsvoeringtoepassingen zoals het invoeren van orders of het opmaken van bezoekrapporten. Ambulancediensten gebruiken bijvoorbeeld elektronische ritformulieren op een tablet


5

waarop een verpleegkundige alle gegevens van een patiënt noteert. En agenten schrijven bijvoorbeeld een bekeuring uit op een smartphone. Het gaat om heel gerichte functionaliteit waarmee gebruikers snel een specifieke business activiteit kunnen ondersteunen. Dit soort kleine apps zullen steeds meer de plaats van grote zware applicaties innemen. B2E apps worden binnen de organisatie verspreid via interne application stores. Op die manier houdt de IT afdeling controle over de apps die de onderneming binnenkomen. Met de opkomst van deze app stores verschuift de rol van IT steeds meer richting marketing gericht op het faciliteren van de eigen werknemers. B2E apps worden vaak voor één platform ontwikkeld omdat er geen tools ("mobile architectures") zijn waarmee applicaties voor alle platformen ontwikkeld kunnen worden. Daarnaast is het bijna ondoenlijk om alle verschillende apparaten en operating systems op een veilige en vertrouwelijke wijze te koppelen aan het bedrijfsnetwerk. Dit staat dan weer op gespannen voet met het Bring Your Own Device (BYOD) principe waarin de medewerkers zelf hun apparatuur aanschaffen. Organisaties gaan daarom vaak over op Choose Your Own Device (CYOD) waarbij de organisatie standaardapparatuur ter beschikking stelt aan de werknemers.


6

2. Agile-softwareontwikkeling Agile-softwareontwikkeling is een manier van softwareontwikkeling. Het Engelse woord agile betekent: behendig, lenig. Gesteld kan worden dat agile en iteratieve ontwikkelmethoden terugkeren naar de ontwikkelpraktijk in de vroege historie van softwareontwikkeling. Oorspronkelijk werden agile-methoden "light weight methods" (lichtgewichtmethoden) genoemd, omdat ze zo weinig regels hadden. Agile-methoden hebben veel gemeenschappelijk met de rapid application development- of RAD-technieken uit de jaren tachtig. Daarna zijn methoden ontwikkeld die later Agile genoemd werden. De bekendste agile-ontwikkelmethoden zijn: 

Scrum (1986)



Dynamic systems development method (DSDM) (1995)



Extreme programming (XP) (1996)



Lean software development

Kenmerken Iteraties De meeste agile-methoden proberen risico's te verminderen door software te ontwikkelen in korte overzichtelijke perioden (timeboxes), die 'iteraties' genoemd worden. Elke iteratie is als het ware een miniatuurproject op zichzelf, en omvat alle noodzakelijke taken: planning, analyse, ontwerp, testen en documentatie. Het is de bedoeling om na iedere iteratie iets bruikbaars op te leveren. Aan het eind van de iteratie wordt het product getoond, getest en het product en proces beoordeeld. Hierdoor wordt het risico beperkt en weet men snel of men op de goede weg zit. Doordat men het product ziet wordt het allemaal concreter en komen er nieuwe ideeën. Aansluitend wordt er dan naar de projectprioriteiten gekeken en bepaald wat er de volgende iteratie (release) gedaan wordt. Communicatie Bij agile-methoden ligt de nadruk op directe communicatie, bij voorkeur als persoonlijk contact, in plaats van geschreven verslaglegging. In agile-projecten wordt erg weinig


7

geschreven documentatie geproduceerd, vergeleken met andere methoden. De meeste agile-teams zijn gehuisvest op één locatie, een zogenaamde "bullpen". Zo mogelijk zijn alle mensen die nodig zijn voor het project in zo'n team ondergebracht. Maar ten minste zijn dit de ontwikkelaars en diegenen die het product definiëren. Dat kunnen productmanagers zijn, businessanalisten of zelfs klanten. In Scrum heeft het team ook geen projectmanagers, maar scrummasters die hiërarchisch niet boven het team staan, maar dit ondersteunen. Dat bevordert zeker de open communicatie tussen de gelijkwaardige teamleden. Bij XP is er ook sprake van pair programming, waarbij twee ontwikkelaars direct samenwerken. Dit is een erg directe manier van communicatie. Voortgang Bij agile-methoden wordt de voortgang afgemeten aan de hand van werkende producten, features of prototypes. Aan het eind van elke iteratie of sprint wordt zowel het opgeleverde product beoordeeld als het ontwikkelproces. Doel is om te leren en steeds beter te worden. Dit aspect, de continue verbetering, (Kaizen) is overgenomen uit de Lean-productiemethoden. Werkende software Er wordt de nadruk gelegd op werkende software. In elke iteratie moet er iets werkends worden opgeleverd. Iets dat ook direct geïntegreerd wordt in de bestaande software, waardoor duidelijk wordt of dit ook allemaal goed gaat.


8

Geschiktheid van agile-methoden Of agile-methoden algemeen geschikt zijn is afhankelijk van het gekozen gezichtspunt. Agile-methoden zijn geschikter naarmate eisen nog vaag en veranderlijk zijn. Vanuit organisatorisch gezichtspunt kan de geschiktheid worden afgemeten aan drie dimensies: cultuur, mensen en communicatie. In dit verband is een aantal succesfactoren aangegeven: 

De cultuur van de organisatie moet openstaan voor discussie en onderhandeling.



Organisaties moeten mensen (fulltime) vrijmaken om besluiten te nemen over wat de organisatie wil en om te testen of het opgeleverde ook daaraan voldoet.



Mensen moeten vertrouwd worden.



Organisaties moeten de beslissingen accepteren die hun afgevaardigden / producteigenaars / product-managers nemen.



Organisaties moeten een omgeving hebben waarin snelle communicatie tussen teamleden mogelijk is.



Mensen moeten kunnen samenwerken.

Grote projecten Grote projecten zijn altijd moeilijk vanwege de benodigde hoeveelheid communicatie, maar dat is juist een sterk punt van de agile methoden. Agile-ontwikkeling is uitgebreid gedocumenteerd om goed te werken in kleine (<10 ontwikkelaars) co-located teams. Voor grootschalige ontwikkelingen (meer dan 20 ontwikkelaars) zijn er voorstellen gedaan. Ook wordt er met agile gewerkt in non-co-located teams die over de hele wereld verspreid kunnen zijn. Schaalgrootte of geografische spreiding op zich zijn kennelijk geen onoverkomelijke barrières voor succes.


9

3. Scrum Scrum is een flexibele manier om (software)producten te maken en is een vorm van Agile-softwareontwikkeling. Er wordt gewerkt in multidisciplinaire teams die in korte sprints, met een vaste lengte van 1 tot 4 weken, werkende (software) producten opleveren. Scrum is een term die afkomstig is uit de rugbysport. Bij een scrum probeert een team samen een doel te bereiken en de wedstrijd te winnen. Samenwerking is heel belangrijk en men moet snel kunnen inspelen op veranderende omstandigheden. Scrum wordt veel gebruikt bij producten waarvan de klant / gebruiker nog niet goed weet wat hij wil en waarbij men al doende leert om de eisen en wensen beter te beschrijven en in bruikbare producten om te zetten. Vaak weet men pas wat men wil als men het eerste product, het prototype, ziet en dan worden alsnog de eisen aangepast. Scrum heeft de flexibiliteit om met laat wijzigende eisen en wensen om te gaan. Doelstellingen 

In korte sprints snel werkende producten opleveren, waardoor snel duidelijk wordt of men goed bezig is. Dit beperkt de risico's van langere projecten waarvan soms pas na een jaar gebruikers / klanten iets kunnen zien / testen.



Snel duidelijkheid over de voortgang.



Korte lijnen, snelle communicatie, teamwerk.



Grotere betrokkenheid teamleden, concentratie op overzichtelijk deel van project

Werkwijze Bij scrum worden de experts bij elkaar in één team gezet, bij voorkeur ook in één ruimte, zodat er makkelijk kan worden samengewerkt. Het team wordt begeleid door een "scrummaster", die zorgt dat het team zich aan de (scrum)regels houdt en kan doorwerken. De product-owner is de klant en voor hem/haar wordt het product gemaakt. Hij geeft ook aan wat er gemaakt moet worden. Dat gebeurt in de vorm van userstories (een soort eisen en wensen (requirements)). Deze user-stories staan op een lijst, de productbacklog. De productbacklog is door de product-owner gesorteerd op belangrijkheid. De belangrijkste user-stories staan bovenaan. De


10

belangrijkste user-stories worden opgenomen in de sprint backlog, dat is wat men in de sprint wil gaan doen. De sprint wordt ook wel de iteratie of de scrum genoemd. In korte sprints worden de user-stories door het ontwikkelteam in kant en klare producten omgezet, inclusief documentatie en (integratie)tests. Het is dus in principe helemaal af. Aan het einde van elke sprint wordt het gewijzigde/verbeterde (software)product in de "Demo" aan de product-owner getoond. Daarna volgt nog een evaluatie waarin het team probeert lessen te trekken uit de afgelopen sprint, zodat men steeds beter wordt.

Rollen Bij Scrum kent men de volgende drie hoofdrollen: Product-Owner De Product-Owner (product eigenaar) is de opdrachtgever / klant. Hij heeft het meeste belang bij het (software)product dat gemaakt wordt. Hij zorgt dat de rekening betaald wordt. Hij / zij beheert ook de product backlog, hij bepaalt wat er moet gebeuren en in welke volgorde. In principe wordt begonnen met het belangrijkste, waar het meeste voordeel mee te behalen is, wat boven aan de product backlog staat. Ontwikkelteam Het ontwikkelteam is multidisciplinair samengesteld en is verantwoordelijk voor het afleveren van het (software)product aan het einde van elke sprint. Het team bestaat meestal uit 3 tot 9 personen. Het team organiseert zichzelf. Zij doen de analyse, ontwerp, ontwikkeling, test en documentatie en zorgen dat er aan het eind van de sprint een kant en klaar product is, dat in principe in productie genomen kan worden. Scrummaster De Scrum Master begeleidt / helpt het team door te zorgen dat het juiste scrumproces gevolgd wordt. Hij verzorgt ook eventuele trainingen. De scrummaster regelt alle


11

vergaderingen. Ook regelt hij de voorzieningen zoals een werkruimte, hardware en software. De scrummaster zorgt ervoor dat het team niet lastig gevallen wordt door derden die met extra eisen tussendoor komen of die bijvoorbeeld tijdelijk mensen nodig hebben uit het team. De scrummaster is geen projectmanager. Hij regelt bijvoorbeeld niet de personele zaken zoals selectie, beoordeling en beloning van de mensen. Dit bevordert de openheid en samenwerking. Kernbegrippen Scrum Daily scrum Elke dag is er de "Daily scrum" waarbij iedereen staat. Deze vergadering heeft de volgende regels: 

De vergadering duurt maximaal 15 minuten, korter mag ook.



Normaal gesproken houdt men een rondje waarbij elk teamlid drie vragen

beantwoordt:  Wat heb je gedaan?  Wat ga je doen?  Zie je ook problemen/uitdagingen (impediments), heb je hulp nodig, zijn er dingen die voor andere teamleden van belang zijn? 

De vergadering mag maximaal 15 minuten duren dus grotere problemen worden

buiten de vergadering verder besproken. De vergadering is net lang genoeg om één kopje koffie, staande, op te drinken.

Sprint backlog In de sprint backlog staat wat er deze sprint wordt gedaan. De sprint backlog wordt samengesteld uit de bovenste items van de product backlog. Het ontwikkelteam bepaalt wat ze kunnen doen gebaseerd op hun snelheid in de vorige sprints.


12

Gebruikelijk is dat de items op de sprint backlog geschreven worden op post-its. Er zijn dan drie kolommen, "to do", "in progress", "done". Soms met een vierde kolom "testing". Zodoende is voor iedereen duidelijk hoe het ermee staat. Het ontwikkelteam bepaalt zelf wie wat doet, of eigenlijk kiezen de leden zelf wat ze (kunnen en willen) oppakken van de todo-lijst. Dit bevordert dat het team zich ermee verbonden voelt, dat ze zich er voor willen inzetten, dat het hun product wordt. Er kunnen na de start geen items meer toegevoegd worden aan de sprint, behalve door het ontwikkelteam zelf. Nadat de sprint klaar is wordt de Product Backlog nog eens tegen het licht gehouden en kunnen prioriteiten en dus de volgorde wijzigen.

Acceptatiecriteria / definition of done In de "Definition of done" staat wat er is afgesproken over hoe men een product oplevert. Eisen over documentatie (Engelstalig), testen (getest door gebruikers en de afdeling beheer, op welke apparaten/webbrowsers), locatie (op de acceptatieomgeving), etc. Verbetering / Increment De "verbetering" (increment) is een lijst van alle gerealiseerde verbeteringen / veranderingen aan het product. Deze lijst wordt in elke sprint, aan het eind van de sprint bijgewerkt. Hierop staan alleen items die voldoen aan de "definition of done". Dit overzicht moet in een vorm zijn die bruikbaar is voor de klant / product-owner. De lijst kan nodig zijn om verdere investeringen in het project te verdedigen en om aan buitenstaanders / klanten / dealers / overheid, duidelijk te maken wat men tot nu toe bereikt heeft. Of deze lijst gebruikt en gepubliceerd wordt, ligt aan de product-owner.


13

Burn down

Dit is een voorbeeld van een "burn down chart" van een voltooide sprint. Men ziet wat er af is en wat er nog gedaan moet worden. De burn down chart van de sprint hangt meestal aan de wand in de projectkamer. Op die manier is voor iedereen direct duidelijk hoeveel er nog gedaan moet worden. Doordat het dagelijks wordt bijgewerkt is direct duidelijk hoe het ervoor staat. Er zijn ook andere typen van "burn down charts" in gebruik, bijvoorbeeld de release burn

down chart hierop staat hoeveel er nog gedaan moet worden voor de volgende release van het product (Er vanuit gaande dat een "release" in meerdere sprints gerealiseerd wordt).


14

4. RUP Rational Unified Process Rational Unified Process of RUP is een iteratief softwareontwikkelingsproces. RUP principes RUP (versie 6) is gebaseerd op een aantal principes en best practices zoals: 

Ontwikkel software incrementeel/iteratief Gezien de tijd die het kost om grote software-systemen te bouwen, is het niet mogelijk om een heel systeem in één keer te maken. Requirements kunnen veranderen in de loop van het traject door technische beperkingen, veranderende eisen/wensen of een beter begrip van het daadwerkelijke probleem. Incrementeel ontwikkelen stelt je in staat om het project op te delen in een aantal deelproducten en deze afzonderlijk van elkaar op te leveren. Dit verkleint het risico dat het eindproduct niet is wat de klant wil en de klant kan nu per deelproduct zijn feedback geven wat je weer kunt meenemen tijdens de ontwikkeling van het volgende deelproduct.



Management van software requirements Requirements management heeft te maken met het achterhalen, vastleggen en beheren van de behoeften van de klant. Daaronder vallen de volgende activiteiten:





Analyseer het probleem



Definieer wat de klant wil



Definieer het op te leveren systeem



Beheer de randvoorwaarden van het systeem



Verfijn de systeemeisen/systeemomschrijvingen



Beheer de wijzigende requirements

Maak gebruik van op componenten gebaseerde architectuur Systemen met een op componenten gebaseerde architectuur zijn eenvoudig uit te breiden, inzichtelijk, begrijpelijk en bevorderen het hergebruik van bepaalde delen code. Aangezien de systemen steeds groter worden neemt het belang van een goede architectuur toe. RUP is erop gericht de basisarchitectuur in een vroeg


15

stadium te bepalen, en naarmate het systeem groter wordt zal de architectuur zich verder uitbreiden. Bij iteratief ontwikkelen is het mogelijk de componenten geleidelijk aan in kaart te brengen om ze vervolgens te ontwikkelen, te kopen of te hergebruiken. 

Maak prototypes Door de gebruiker een grafische voorstelling te geven van het product (prototyping), verkleint de faalkans van het project. Een globale, grafische oplossing voor het probleem is door de gebruiker beter te begrijpen dan pagina's vol broncode. Het is een versimpeling van de complexiteit. Naast prototypes komen in deze fase ook use cases, use case diagrammen, klassediagrammen en andere objecten naar voren.



Test het systeem Het bepalen van de kwaliteit van een systeem gebeurt op basis van testen. Dit is een van de punten waarop software projecten vaak falen omdat het testen vaak aan het einde van het project wordt gedaan, soms helemaal niet en soms door andere teams. RUP vangt dit probleem af door het testen in het gehele proces terug te laten komen en daarbij alle belanghebbenden (stakeholders) te betrekken (zowel programmeurs als klanten). RUP gaat ervan uit dat elke belanghebbende verantwoordelijk is voor de kwaliteit gedurende het gehele project.



Maak gebruik van versiebeheer tijdens de software-ontwikkeling. Zoals bij alle andere software-projecten zijn veranderingen in de software onvermijdelijk. RUP beschrijft een aantal methoden om deze veranderingen te beheersen en nauwkeurig te volgen. RUP beschrijft ook beveiligde werkruimtes, hierin staat bijvoorbeeld dat het systeem van een programmeur niet aangetast mag worden door veranderingen in een ander systeem.

RUP Fasering RUP verdeelt een project in 4 hoofdfasen : 

Inceptiefase (Aanvang) De haalbaarheid van het project, de inhoud (scope) en de begrenzingen worden bepaald. Gedurende de inceptiefase wordt het oorspronkelijke idee omgezet in een productvisie (vision). De business drivers worden geëvalueerd om ze helder te krijgen. De globale kostprijs en de verwachte baten van het project worden geschat. De belangrijkste risico's worden geïdentificeerd en ingeschat. Het


16

uiteindelijke doel van deze fase is een haalbaarheidsstudie (business case) voor het project, of anders gesteld een GO/NOGO voor het project. 

Elaboratiefase (Detaillering) Het merendeel van de functionele requirements (use cases) wordt gespecificeerd en de systeemarchitectuur wordt ontworpen. De focus ligt op de technische haalbaarheid van het project. Uiteindelijke doel van deze fase is een projectplan, waarin onder meer de gedetailleerde inhoud (scope), timing (schedule) en kostenraming (estimations) voor het project zijn opgenomen.



Constructiefase (Bouw) Het product wordt ontwikkeld vanaf de architectuur tot een systeem dat compleet genoeg is om te testen.



Transitiefase (Overgang) Via testen wordt het product gevalideerd door de belanghebbenden. Andere activiteiten in deze fase zijn: voorbereiding en in productie name (deployment), nazorg, en overdracht van de verantwoordelijkheden. Deze fase wordt afgesloten met een inventarisatie van de opgedane ervaringen (lessons learned) voor volgende projecten.


17

5. Functies in de informatievoorziening Bij de ontwikkeling van een informatiesysteem werken veel mensen met elkaar samen. De volgende functies spelen een rol in een ontwikkeltraject: Informatiemanager De informatie Manager heeft de eindverantwoordelijkheid voor de informatievoorziening binnen een organisatie. De Informatie Manager is echter een (ook adviserende) staffunctie, soms als staf van een directie. De Informatie Manager stelt het concept informatiebeleid op en laat dit goedkeuren door de directie. De informatiemanager heeft vanuit de stafpositie de verantwoordelijkheid voor de informatievoorziening in een organisatie. Stelt de informatievoorziening architectuur op en definieert projecten. Soms heeft de Informatie Manager ook een direct sturende rol in het kader van de realisatie van de informatievoorziening. Een Informatie Manager komt vooral voor in grote organisaties. Alternatieve naam: informatiecoördinator. Taken: 

Opstellen informatiebeleid o Inventariseren, analyseren, definiëren en afstemmen van doelstellingen, uitgangspunten en randvoorwaarden voor de informatievoorziening en de automatisering, afgestemd op het bedrijfsbeleid.



Opstellen informatieplan o Inventariseren, analyseren, afstemmen en beschrijven van de gewenste informatievoorziening van een organisatie, in relatie met de gewenste bedrijfsvoering. o Vaststellen van uitgangspunten, condities en randvoorwaarden. Beschrijven van de eisen die aan de gewenste situatie worden gesteld, alsmede de consequenties voor de bestaande situatie.



Opstellen plan voor interne controle


18

o Formuleren van eisen inzake interne controle van de informatievoorziening. Beoordelen van de bestaande maatregelen en voorzieningen in het licht van deze eisen. o Bepalen en beschrijven van wenselijke (aanvullende) maatregelen. 

Opstellen projectenplan o Definiëren van projecten ten behoeve van de ontwikkeling of aanpassing van informatiesystemen, applicaties, databases, technische infrastructuur, etc. Vaststellen van de samenhang tussen de projecten en faseren in de tijd. Inventariseren van de conditionerende maatregelen, randvoorwaarden, e.d. Inschatten van de per project benodigde tijd, doorlooptijd, mensen en (financiële) middelen.



Vaststellen gewenste situatie informatievoorziening o Inventariseren, analyseren, afstemmen en beschrijven van de gewenste informatievoorziening in relatie met de gewenste bedrijfsvoering. Vaststellen van beperkingen, randvoorwaarden en uitgangspunten. Beschrijven van de eisen die aan de gewenste situatie worden gesteld.



Goedkeuren/beoordelen opdracht, verzoek, e.d. o Beoordelen, goedkeuren of zo nodig laten aanpassen van een opdracht. o Eventueel formuleren van condities, e.d. Toewijzen van de opdracht aan één of meerdere medewerkers, deskundigen.



Afbakenen onderzoeksgebied o Nader verkennen en afbakenen van het onderzoeksgebied dat in een opdracht (globaal) is vastgelegd. Beschrijven van de relaties met andere onderzoeksgebieden.



Opstellen normen, criteria, randvoorwaarden o Analyseren en opstellen van normen, criteria, randvoorwaarden, etc. ten behoeve van het nemen van beslissingen en beoordelen van situaties.



Organiseren informatievoorzieningsfunctie o Definiëren van de taken, verantwoordelijkheden, bevoegdheden, functies, procedures, processen en de organisatiestructuur voor het plannen, ontwikkelen, beheren en exploiteren van de informatievoorziening.



Formuleren eisen aan ICT-dienstverlening o Analyseren van de eisen, randvoorwaarden, condities, e.d. waaronder een (interne of externe) leverancier haar diensten moet aanbieden.



Bepalen investeringen en kosten


19

o Berekenen van de investeringen en kosten van bijvoorbeeld projecten, de aanschaf en afschrijving van hardware, of het bepalen van de kosten van het beheer van een component. 

Beheren bedrijfswaarde van componenten o Berekenen van de kosten van bijvoorbeeld het beheer en het gebruik van informatiesystemen, apparatuur, e.d. Deze kosten afzetten tegen de opbrengsten van de inzet van deze middelen. o Zo nodig aansturen op het verbeteren van het gebruik en de inzet van betreffende middelen en/of het aansturen op het verlagen van bijvoorbeeld de beheer- en exploitatiekosten.

Business Systems Analist De Business Systems Analist is vooral actief bij het ontwikkelen, verbeteren en implementeren van (de workflow van) bedrijfsprocessen. Inherent daaraan werkt de business analist mee aan het vaststellen en verbeteren van de informatievoorziening in het algemeen, individuele informatiesystemen, e.d. om de bedrijfsprocessen optimaal te ondersteunen. Deze functie komt in grote tot zeer grote organisaties voor, alsmede als specialisme van een consultant van een organisatie adviesbureau. Alternatieve functienaam: Business consultant. Taken: 




Vaststellen informatie-architectuur o Definiëren van de gewenste informatievoorziening van een organisatie. o Aangeven van de consequenties voor de bestaande situatie.



Opstellen plan voor interne controle


20

o Formuleren van eisen inzake interne controle van de informatievoorziening. Beoordelen van de bestaande maatregelen en voorzieningen in het licht van deze eisen. o Bepalen en beschrijven van wenselijke (aanvullende) maatregelen. 

Opstellen beveiligingsplan o Formuleren van eisen inzake de beveiliging van de informatievoorziening met betrekking tot het voorkomen van het verlies aan gegevens en de ongeautoriseerde toegang tot gegevens. Beoordelen van de bestaande maatregelen en voorzieningen in het licht van deze eisen. o Bepalen en beschrijven van wenselijke (aanvullende) maatregelen.



Bepalen normen systeemgebruik en -beheer o Formuleren van het beleid ter zake. o Opstellen van normen, richtlijnen en procedures voor het gebruik en beheer van informatiesystemen. Beheren en onderhouden van de normen.



Probleemoriëntatie informatievoorziening o Op hoofdlijnen analyseren en beschrijven van een vraagstuk of probleem in de informatievoorziening, al dan niet voortkomend uit een bedrijfskundig vraagstuk. Nader verkennen van het vraagstuk of probleem om vast te stellen of er een opdracht moet worden gegeven om het ondervonden probleem verder te analyseren en op te lossen.



Onderzoeken organisatieaspecten o Uitvoeren van het onderzoek om een beeld te krijgen van het functioneren van de organisatie en van relevante aspecten en ontwikkelingen, mede in het licht van geformuleerde knelpunten, problemen, wijzigingen, e.d. in de (gebruikers)organisatie.



Analyseren veranderingsvermogen o Vaststellen van het veranderingsvermogen van de organisatie in relatie tot veranderingen in de informatievoorziening. Afleiden van organisatorische randvoorwaarden en toetsingscriteria voor de te kiezen oplossingen en wijzigingen in de informatievoorziening.





21



Opstellen bedrijfsprocessen model o Vaststellen welke bedrijfsprocessen objecten creëren, onderhouden en gebruiken in het kader van een specifiek informatiesysteem. o Specificeren van de relaties tussen:



-

de bedrijfsprocessen onderling,

-

de bedrijfsprocessen en de objecten,

-

de bedrijfsprocessen en de omgeving.

Ontwerpen bedrijfsproces o Vaststellen op welke wijze bedrijfsprocessen moeten functioneren en moeten worden ingericht. Vastleggen in een procesbeschrijving. Formuleren van de eisen aan en criteria aan de resultaten van de bedrijfsprocessen.



Opstellen calamiteitenplan o Onderzoeken van de noodzaak om de functionaliteit van een informatiesysteem (zowel interactief/online gebruik als de batch-productie) op een alternatieve wijze te continueren indien het primaire productiesysteem gedurende een onacceptabele periode dreigt uit te vallen, c.q. uitvalt. Formuleren van de eisen aan en criteria voor calamiteiten. Onderzoeken van de mogelijkheden voor een calamiteitenregeling. Opstellen van een actieplan waarmee de gekozen calamiteitenregelingen kunnen worden gerealiseerd.



Opstellen informatieprocessen model o Vaststellen in welke informatieprocessen gegevens worden gecreëerd, onderhouden en gebruikt. o Specificeren van de relaties tussen:



-

de informatieprocessen onderling,

-

de informatieprocessen en gegevens,

-

de informatie-uitwisseling met de omgeving.

Bepalen investeringen en kosten o Berekenen van de investeringen en kosten van bijvoorbeeld projecten, de aanschaf en afschrijving van hardware, of het bepalen van de kosten van het beheer van een component.



Beheren bedrijfswaarde van componenten o Berekenen van de kosten van bijvoorbeeld het beheer en het gebruik van informatiesystemen, apparatuur, e.d. Deze kosten afzetten tegen de opbrengsten van de inzet van deze middelen.


22

o Zo nodig aansturen op het verbeteren van het gebruik en de inzet van betreffende middelen en/of het aansturen op het verlagen van bijvoorbeeld de beheer- en exploitatiekosten. Informatie Architect Een Informatie Architect stelt - meestal vanuit de principes van architectuur - de informatie-architectuur op. Hierbij wordt zeer sterk gekeken naar het optimaliseren van de bedrijfsprocessen. Een belangrijk aandachtspunt is de integratie van informatiesystemen binnen een concern, alsmede met systemen van klanten, e.d. Deze functie komt vooral bij grote tot zeer grote organisaties voor. Taken: 







Opstellen plan voor interne controle o Formuleren van eisen inzake interne controle van de informatievoorziening. Beoordelen van de bestaande maatregelen en voorzieningen in het licht van deze eisen. o Bepalen en beschrijven van wenselijke (aanvullende) maatregelen.



Opstellen beveiligingsplan o Formuleren van eisen inzake de beveiliging van de informatievoorziening met betrekking tot het voorkomen van het verlies aan gegevens en de ongeautoriseerde toegang tot gegevens. Beoordelen van de bestaande maatregelen en voorzieningen in het licht van deze eisen. o Bepalen en beschrijven van wenselijke (aanvullende) maatregelen.



Probleemoriëntatie informatievoorziening


23

o Op hoofdlijnen analyseren en beschrijven van een vraagstuk of probleem in de informatievoorziening, al dan niet voortkomend uit een bedrijfskundig vraagstuk. Nader verkennen van het vraagstuk of probleem om vast te stellen of er een opdracht moet worden gegeven om het ondervonden probleem verder te analyseren en op te lossen. 

Onderzoeken organisatieaspecten o Uitvoeren van het onderzoek om een beeld te krijgen van het functioneren van de organisatie en van relevante aspecten en ontwikkelingen, mede in het licht van geformuleerde knelpunten, problemen, wijzigingen, e.d. in de (gebruikers)organisatie.









Opstellen objectmodel o Analyseren, definiëren en specificeren van objecten, hun kenmerken, hun onderlinge relaties en hun relaties met de omgeving.






-


-


-


Opstellen informatieprocessen model o Vaststellen in welke informatieprocessen gegevens worden gecreëerd, onderhouden en gebruikt. o Specificeren van de relaties tussen: -



24



-


-


Vaststellen informatiesysteemarchitectuur o Definiëren van een gewenst informatiesysteem in termen van: -

subsystemen,

-

databases en andere gegevensverzamelingen,

-

de wijze van gegevensopslag en -verwerking,

-

de interactie met de gebruikers ('user interface') en de onderlinge

samenhang. 

Opstellen gegevensmodel o Analyseren, definiëren en specificeren van gegevens over objecten in hun onderlinge samenhang. Toetsen van het gegevensmodel op volledigheid, duidelijkheid, consistentie en andere normen.

Informatie Analist De Informatie Analist inventariseert door middel van een organisatie onderzoek en analyseert behoeften aan informatie en informatiesystemen in een organisatie. Analyseert de bedrijfsprocessen en stelt de requirements (eisen en wensen van de gebruikers) vast. Vertaalt deze onderzoeksresultaten in een informatie architectuur. Voor een specifiek systeem ontwikkelt deze ook de informatiesysteemarchitectuur. Analyseert daarbij vaak ook de gegevensstructuren en -definities. Taken: 




Probleemoriëntatie informatievoorziening o Op hoofdlijnen analyseren en beschrijven van een vraagstuk of probleem in de informatievoorziening, al dan niet voortkomend uit een bedrijfskundig vraagstuk. Nader verkennen van het vraagstuk of probleem om vast te stellen of er een opdracht moet worden gegeven om het ondervonden probleem verder te analyseren en op te lossen.



Onderzoeken organisatieaspecten o Uitvoeren van het onderzoek om een beeld te krijgen van het functioneren van de organisatie en van relevante aspecten en ontwikkelingen, mede in het licht


25

van geformuleerde knelpunten, problemen, wijzigingen, e.d. in de (gebruikers)organisatie. 













-


-


-



subsystemen,

-


-


-


samenhang. 

Vaststellen oplossingsalternatieven o Ontwikkelen van alternatieven om de gewenste situatie van de informatievoorziening, applicaties, technische infrastructuur, e.d. te bereiken. Opstellen van selectiecriteria. o Formuleren van aanbevelingen.



Afbakenen onderzoeksgebied


26

o Nader verkennen en afbakenen van het onderzoeksgebied dat in een opdracht (globaal) is vastgelegd. Beschrijven van de relaties met andere onderzoeksgebieden. 

Opstellen normen, criteria, randvoorwaarden o Analyseren en opstellen van normen, criteria, randvoorwaarden, etc. ten behoeve van het nemen van beslissingen en beoordelen van situaties.



Opstellen kwaliteitsplan o Analyseren van eisen, normen, randvoorwaarden en condities. Formuleren van kwaliteitscriteria en planning van activiteiten om processen en componenten van een informatiesysteem aan gestelde eisen te laten voldoen.



Uitvoeren analyse o Op basis van opdrachten of ter ondersteuning van de eigen werkzaamheden uitvoeren van analyses.



Uitvoeren risicoanalyse o Inventariseren, analyseren en beoordelen van (project)risico's. o Formuleren van beheersmaatregelen.



Bepalen investeringen en kosten o Berekenen van de investeringen en kosten van bijvoorbeeld projecten, de aanschaf en afschrijving van hardware, of het bepalen van de kosten van het beheer van een component.



Beheren bedrijfswaarde van componenten o Berekenen van de kosten van bijvoorbeeld het beheer en het gebruik van informatiesystemen, apparatuur, e.d. Deze kosten afzetten tegen de opbrengsten van de inzet van deze middelen. o Zo nodig aansturen op het verbeteren van het gebruik en de inzet van betreffende middelen en/of het aansturen op het verlagen van bijvoorbeeld de beheer- en exploitatiekosten.

Systeemontwerper De systeemontwerper stelt in overleg met gebruikers en opdrachtgevers de functionele specificaties van informatiesystemen vast en ontwerpt op basis hiervan het functionele ontwerp. Geeft de contouren aan van de technische oplossing. Beheert en onderhoudt de ontwerpen.


27

Systeemontwerper komt voor in kleinere organisaties waar geen verbijzondering plaatsvindt naar 'Functioneel' en 'Technisch' Systeemontwerper. Alternatieve functienaam: Application Designer. Taken: 










-


-


-



subsystemen,

-


-


-


samenhang. 




Ontwerpen functionele specificaties o Analyseren, opstellen en beschrijven van functionele specificaties van elk te automatiseren informatiefunctie. Toetsen van het geheel op volledigheid, duidelijkheid en consistentie.


28



Ontwerpen applicatiestructuur o Bepalen, detailleren en beschrijven van dialoogstructuren voor de interactieve/on-line informatiefuncties en de structuur van de programma's van batch-informatiefuncties.



Ontwerpen programmaspecificaties o Vaststellen en beschrijven van de systeemdelen (bouwstenen, modules, routines, functies van programma's, waaronder begrepen Internetapplicaties). Specificeren van de invoer, het ontwerpen van de opslag, uitvoer en presentatie van gegevens op beeldschermen en op papier, en eventuele andere opslagmedia.



Selecteren applicatiepakket o Onderzoeken van de in de markt beschikbare (commercieel van leveranciers verkrijgbare) applicatiepakketten. Toetsen en zo nodig aanvullen van de eisen en wensen die worden gesteld aan de functionaliteit en de technische aspecten en eisen van betreffende pakketten. o Kiezen van een applicatiepakket.



Ontwerpen mens/machine interface o Ontwerpen van beeldschermopmaak, de verdeling van systeemfuncties over verschillende schermen, de lay-out van uitvoer en andere situaties waar een mens met een computersysteem werkt.



Ontwerpen handmatige informatiefuncties o Vaststellen en beschrijven van procedures en formulieren voor nietgeautomatiseerde informatiefuncties.






Bepalen conversiestrategie o Inventariseren en analyseren van de voorwaarden en wensen die moeten worden vervuld bij de technische overgang van het bestaande naar het nieuwe systeem. Opstellen van een plan van aanpak voor de conversie van gegevens.



Maken testplan


29

o Vaststellen van de uitgangspunten van testen, de testprocedures, de testgebieden, de testomgeving en de te gebruiken teststrategie, -methoden, technieken en -hulpmiddelen. o Specificeren van de testgegevens, de benodigde startsituatie en de uitvoerverwachtingen per testgebied. 

Uitvoeren test o Toetsen van componenten, programma's, informatiesystemen, integratie van componenten, apparatuur, netwerken, etc. aan de gedefinieerde eisen. Uitvoeren van het testplan.



Beheren functionaliteit applicatie o Bewaken, monitoren, analyseren en bepalen in hoeverre een applicatie (nog) voldoet aan gestelde of gewijzigde functionele eisen, normen, criteria, voorwaarden, etc. o Formuleren en initiëren van adaptieve, preventieve en correctieve wijzigingen.



Bepalen onderhoud op applicaties o Analyseren van het functioneren van de componenten van het informatiesysteem ten opzichte van (bij)gestelde eisen. Analyseren van wijzigingsvoorstellen. Vertalen van functionele wijzigingsvoorstellen in onderhoudsactiviteiten op de applicatie.



Uitvoeren onderhoud op applicaties o Analyseren, uitvoeren en beoordelen van de realisatie van voorstellen voor wijzigingen in een applicatie. Op elkaar afstemmen van wijzigingen in verschillende applicaties en mede daarmee samenhangende wijzigingen in de technische infrastructuur. o Testen van de wijzigingen aan (bij)gestelde eisen.

Programmeur De Programmeur ontwerpt en bouwt op basis van het technisch ontwerp programmatuur. Soms stelt Programmeur ook de programmaspecificaties en de applicatiestructuur op in samenwerking met een (Technisch) Ontwerper. Programmeur voert programmatesten uit. Programmeur voert ook het onderhoud op programmatuur uit en draagt zorg voor het optimaliseren van de prestatiekenmerken van de applicatie. Deze functie komt in de meeste organisaties voor. Alternatieve functienamen: 4GL ontwikkelaar en Applicatieprogrammeur


30

Taken: 

Ontwerpen applicatiestructuur o Bepalen, detailleren en beschrijven van dialoogstructuren voor de interactieve/online informatiefuncties en de structuur van de programma's van batch-informatiefuncties.



Ontwerpen programmaspecificaties o Vaststellen en beschrijven van de systeemdelen (bouwstenen, modules, routines, functies van programma's, waaronder begrepen Internetapplicaties). Specificeren van de invoer, het ontwerpen van de opslag, uitvoer en presentatie van gegevens op beeldschermen en op papier, en eventuele andere opslagmedia.



Maken programma, applicatiecomponent o Ontwerpen, vervaardigen, documenteren en onderhouden van een onderdeel (bouwsteen, component) van een informatiesysteem. o Controleren van de werking conform de specificaties (testen).



Maken eindgebruikerstoepassing o Analyseren van behoeften, ontwerpen en bouwen van (relatief eenvoudige) applicaties met behulp van standaard pakketten.



Maken testplan o Vaststellen van de uitgangspunten van testen, de testprocedures, de testgebieden, de testomgeving en de te gebruiken teststrategie, -methoden, technieken en -hulpmiddelen. o Specificeren van de testgegevens, de benodigde startsituatie en de uitvoerverwachtingen per testgebied.









Uitvoeren onderhoud op applicaties


31

o Analyseren, uitvoeren en beoordelen van de realisatie van voorstellen voor wijzigingen in een applicatie. Op elkaar afstemmen van wijzigingen in verschillende applicaties en mede daarmee samenhangende wijzigingen in de technische infrastructuur. o Testen van de wijzigingen aan (bij)gestelde eisen. Webdesigner De Web Designer stelt op basis van functionele specificaties het ontwerp van een website op, inclusief de achterliggende applicatie en databases. Deze functie is vergelijkbaar met die van (Functioneel) Ontwerper, maar specifiek gericht op toepassingen op het Internet. Een bijzonder specialisatie van de Web Designer is de vormgeving (ergonomische aspecten) van de website. Web Designer stuurt de eventuele Technisch Ontwerpers en Programmeurs aan voor de realisatie van de website. Web Designers komen voor bij de bedrijven die zich op het Internet willen presenteren of dit als marketing en verkoopkanaal willen gebruiken. De functie komt ook voor als bijzonder specialisme van een consultant van een software house of zich op Internet gespecialiseerd bedrijf. Alternatieve functienamen: Web Ontwikkelaar, Web Developer, Web Architect. Taken: 




-


-


-



subsystemen,

-


-


-


samenhang.


32






Ontwerpen functionele specificaties o Analyseren, opstellen en beschrijven van functionele specificaties van elk te automatiseren informatiefunctie. Toetsen van het geheel op volledigheid, duidelijkheid en consistentie.



Selecteren applicatiepakket o Onderzoeken van de in de markt beschikbare (commercieel van leveranciers verkrijgbare) applicatiepakketten. Toetsen en zo nodig aanvullen van de eisen en wensen die worden gesteld aan de functionaliteit en de technische aspecten en eisen van betreffende pakketten. o Kiezen van een applicatiepakket.



Ontwerpen mens/machine interface o Ontwerpen van beeldschermopmaak, de verdeling van systeemfuncties over verschillende schermen, de lay-out van uitvoer en andere situaties waar een mens met een computersysteem werkt.



Ontwerpen handmatige informatiefuncties o Vaststellen en beschrijven van procedures en formulieren voor nietgeautomatiseerde informatiefuncties.






Bepalen conversiestrategie o Inventariseren en analyseren van de voorwaarden en wensen die moeten worden vervuld bij de technische overgang van het bestaande naar het nieuwe systeem. Opstellen van een plan van aanpak voor de conversie van gegevens.



Maken testplan o Vaststellen van de uitgangspunten van testen, de testprocedures, de testgebieden, de testomgeving en de te gebruiken teststrategie, -methoden, technieken en -hulpmiddelen.


33

o Specificeren van de testgegevens, de benodigde startsituatie en de uitvoerverwachtingen per testgebied. 




Beheren functionaliteit applicatie o Bewaken, monitoren, analyseren en bepalen in hoeverre een applicatie (nog) voldoet aan gestelde of gewijzigde functionele eisen, normen, criteria, voorwaarden, etc. o Formuleren en initiëren van adaptieve, preventieve en correctieve wijzigingen.






Uitvoeren onderhoud op applicaties o Analyseren, uitvoeren en beoordelen van de realisatie van voorstellen voor wijzigingen in een applicatie. Op elkaar afstemmen van wijzigingen in verschillende applicaties en mede daarmee samenhangende wijzigingen in de technische infrastructuur. o Testen van de wijzigingen aan (bij)gestelde eisen.


34

6. Kwaliteit Kwaliteit van de informatie en de informatieverzorging De kwaliteit van de informatie en de informatieverzorging kan vanuit verschillende invalshoeken beschouwd worden: 

Kwaliteitsaspecten van de informatie Informatiedimensie: de informatie die door het systeem als uitvoer wordt geproduceerd.



Statische kwaliteitsaspecten van de informatievoorziening 1 De intrinsieke eigenschappen van het informatiesysteem en de documentatie, gezien vanuit het standpunt van de ontwikkelaar en van de toekomstige beheerder.



Dynamische kwaliteitsaspecten van de informatieverzorging Het functioneren van het systeem, gezien vanuit het standpunt van de gebruiker.

Kwaliteitsaspecten van de informatie 

Juistheid van de informatie De mate waarin de geproduceerde informatie een waarheidsgetrouwe afbeelding van de werkelijkheid vormt. De juistheid van de informatie is het product van de juistheid van de invoer en de juistheid van de verwerking. De gebruiker moet er op kunnen vertrouwen dat de informatie verantwoord kan worden gebruikt voor het doel dat deze wordt verschaft.



Volledigheid van de informatie De mate waarin de geproduceerde informatie alle gegevenselementen bevat die voor het doel waarvoor de informatie verstrekt wordt relevant zijn. De volledigheid van de informatie is het product van de volledigheid van de ingevoerde gegevens en de volledigheid van de verwerking. Zowel het ontbreken van gegevens, als het dubbel voorkomen (bijvoorbeeld spellingvarianten van dezelfde persoonsnaam) zijn voorbeelden van onvolledigheid. Overbodige

1

De informatievoorziening maakt onderdeel uit van de informatieverzorging


35

gegevens (die niet nodig zijn voor het doel) veroorzaken redundantie. In combinatie met aspect Juistheid wordt bij Volledigheid dus de vraag gesteld of de informatie de waarheid weergeeft, de hele waarheid en niets dan de waarheid. 

Relevantie van de informatie De mate waarin de gegevenselementen van belang zijn voor het doel dat de informatie heeft. Informatie is relevant als deze is afgestemd op de problemen en behoeften van de gebruiker.



Actualiteit van de informatie De mate waarin de informatie de werkelijkheid weergeeft zoals die is op het moment dat de informatie wordt geproduceerd. De actualiteit van de informatie is opgebouwd uit de actualiteit van de invoer en de snelheid van de verwerking. De actualiteit kan worden uitgedrukt in de hoeveelheid tijd die de informatie (gemiddeld) achterloopt op de werkelijkheid. De norm moet worden afgeleid van de tijdigheidseis.



Nauwkeurigheid van de informatie Informatie moet zo nauwkeurig zijn als voor het gebruiksdoel noodzakelijk is. Het bedrag dat op een rekening staat, moet tot op de cent nauwkeurig zijn. Wanneer echter overzichten over de omzet van een bepaald jaar aan de directeur worden verstrekt, wordt deze bijvoorbeeld uitgedrukt in miljoenen guldens.

De aspecten nauwkeurigheid en actualiteit (actualiteit kan worden beschouwd als nauwkeurigheid in tijd) hebben pas zin als de juistheid en volledigheid van de informatie vaststaan. Vervolgens moet men de norm bepalen in relatie met het doel van de informatieverstrekking. Het spreekt voor zich dat alle kwaliteitsaspecten controleerbaar moeten zijn; het moet te controleren zijn in welke mate aan een bepaald aspect wordt voldaan.


36

Statische kwaliteitsaspecten van de informatievoorziening (van het informatiesysteem) 

Flexibiliteit van het informatiesysteem De mate waarin de gebruiker zelf uitbreidingen of variaties op het informatiesysteem kan aanbrengen zonder dat de programmatuur wordt aangepast. Ofwel de mate waarin het systeem door de beheersorganisatie kan worden aangepast, zonder afhankelijk te zijn van de automatiseringsafdeling voor onderhoud. De flexibiliteit van een informatiesysteem kan onder andere verhoogd worden door het gegevensmodel op een hoger abstractieniveau te tillen. Dit kan variëren van het definiëren van tabellen met parameters om een beperkte flexibiliteit te bereiken, tot het splitsen van het gegevensmodel in een metaniveau en een concreet niveau bij zeer hoge flexibiliteitseisen. Hierbij dient het kwaliteitsaspect van de flexibiliteit te worden afgewogen tegen de gevolgen voor de bruikbaarheid van het systeem.



Onderhoudbaarheid van het informatiesysteem Het gemak waarmee de programmatuur kan worden aangepast hetzij aan nieuwe wensen van de gebruiker (perfectief onderhoud), hetzij om fouten te herstellen (correctief onderhoud). De onderhoudbaarheid hangt sterk af van de volgende factoren: o De toegankelijkheid, consistentie en actualiteit van de documentatie, die op zijn beurt weer wordt bepaald door de kwaliteit van het documentatiebeheerssysteem (de mooiste documentatiesystemen bestaan uit CASE tools rond een systeemencyclopedie). Een goed documentatiesysteem kan door middel van kruis-referentietabellen ook inzicht geven in de samenhang tussen programma's, modules, gegevens enz. o De mate van scheiding tussen gegevensbenadering en verwerking; dit is het principe van data-independency, waardoor aanpassingen in het gegevensmodel separaat kunnen worden uitgevoerd, zonder dat ze uitstralen naar alle processen die van die gegevens gebruik maken. In veel 4GL's en DBMS-en is dit principe al automatisch ingebouwd. o De gestructureerdheid van het systeem: is het systeem op een logische manier verdeeld in subsystemen, informatiefuncties enz.


37

o De toegankelijkheid van de programmatuur zelf: zijn de programma's doorzichtig en gestructureerd opgezet volgens het KISS-principe (Keep It Stupid and Simple). o De modulariteit van het systeem: hoeveel functionaliteit is ondergebracht in (herbruikbare) modules? 

Testbaarheid van het informatiesysteem Het gemak en de snelheid waarmee de functionaliteit en het prestatieniveau van het systeem (na iedere aanpassing opnieuw) getest kunnen worden. Bij de systeemtest wordt gebruik gemaakt van de ontwerpkennis van het systeem; dit betekent dat de testbaarheid voor de ontwikkelaars toeneemt naarmate het systeem beter is gedocumenteerd, gestructureerd en gemodulariseerd, kortom dezelfde factoren die ook de onderhoudbaarheid bepalen. De acceptatietest beschouwt het systeem als een black box; dit betekent dat de testbaarheid voor de opdrachtgever vooral afhangt ten eerste van de toegankelijkheid en volledigheid van zijn testset en ten tweede van de kwaliteit van de testomgeving en de hulpmiddelen die daarbij horen voor het beheren van een reproduceerbare testset, het vergelijken van testresultaten enz.



Portabiliteit van het informatiesysteem De diversiteit van de hardware- en systeemsoftware-omgevingen waarin het informatiesysteem kan draaien, en het gemak waarmee het systeem kan worden overgebracht van de ene omgeving naar een andere. Men kan portabiliteit naar een bepaalde omgeving kwantificeren door de kosten van het aanpassen (het adaptief onderhoud) uit te drukken als een percentage van de kosten van herbouw in de nieuwe omgeving. Portabiliteit is vooral van belang: o Voor pakketontwikkelingen om de potentiële markt zo groot mogelijk te maken. o Om een groeipad te bieden voor informatiesystemen waarbij de hoeveelheid te verwerken gegevens in de toekomst kan toenemen.



Externe connectiviteit van het informatiesysteem Het gemak waarmee een koppeling met andere informatiesystemen tot stand kan worden gebracht.



Interne connectiviteit van het informatiesysteem De mate waarin de diverse onderdelen van het informatiesysteem op elkaar aansluiten en het gemak waarmee die aansluitingen aangepast kunnen worden. De connectiviteit kan sterk worden bevorderd door standaardisatie, denk


38

bijvoorbeeld aan de OSI-standaarden. Bij informatiesystemen die een hoge externe connectiviteit hebben, spreekt men van een open architectuur. 

Herbruikbaarheid van het informatiesysteem De mate waarin delen van het informatiesysteem, of van het ontwerp, opnieuw gebruikt kunnen worden voor de ontwikkeling van andere toepassingen. Dit kwaliteitsaspect is uiteraard vooral van belang voor organisaties die nog meer vergelijkbare toepassingen willen ontwikkelen. Wanneer het systeem in hoge mate gebaseerd is op herbruikbare modulen, zal dit ook aan de onderhoudbaarheid (aspect II.2) ten goede komen.



Geschiktheid infrastructuur van het informatiesysteem De geschiktheid van de apparatuur, het netwerk, de systeemsoftware en het DBMS voor de betreffende toepassing en de mate waarin deze infrastructuurelementen op elkaar aansluiten.

Dynamische kwaliteitsaspecten van de informatieverzorging 

Betrouwbaarheid van de informatieverzorging De redelijke zekerheid dat de verwerking van de gegevens juist, volledig, geoorloofd en tijdig geschiedt. De attributen van dit kwaliteitsaspect zijn: o Juistheid van de verwerking De mate waarin het systeem de aangeboden invoer en mutaties correct volgens de specificatie verwerkt tot consistente gegevensverzamelingen, zelfs als bewust getracht wordt het systeem anders te laten functioneren. o Volledigheid van de verwerking De zekerheid dat het systeem alle invoer en mutaties verwerkt, zodat in de gegevensverzamelingen geen doublures of manco's ontstaan. o Geoorloofdheid van de verwerking Definitie: De mate waarin men kan garanderen dat de gegevens en de programmatuur alleen gemuteerd of geraadpleegd kunnen worden (hetzij rechtstreeks, hetzij via het informatiesysteem) door personen die daartoe bevoegd zijn (ook wel genoemd: vertrouwelijkheid). o Tijdigheid van de verwerking De mate waarin de informatie op tijd beschikbaar komt om de (stuur-) maatregelen te nemen waarvoor die informatie bedoeld was. De norm voor tijdigheid hangt dus volstrekt af van het primair proces dat door


39

de informatievoorziening wordt ondersteund. Het zal duidelijk zijn dat de tijdigheidsnorm voor een reserveringssysteem van een andere orde is dan die voor een boekhouding. 

Continuïteit van de informatieverzorging De redelijke zekerheid dat de gegevensverwerking ongestoord voortgang zal kunnen vinden, dat wil zeggen ook na ernstige storingen binnen redelijke termijn kan worden hervat. De attributen van dit kwaliteitsaspect zijn: o Bedrijfszekerheid De mate waarin de gegevensverwerking vrij blijft van storingen. De bedrijfszekerheid is uit te drukken in de gemiddelde tijd dat het goed gaat (MTBF: Mean Time Between Failures). o Robuustheid De mate waarin de informatievoorziening ook na een storing gewoon door kan gaan. o Herstelbaarheid Het gemak en de snelheid waarmee de informatievoorziening hersteld kan worden na een storing. De herstelbaarheid kan worden uitgedrukt in de gemiddelde duur van de onderbreking van de informatievoorziening na een storing (MTTR: Mean Time To Repair). De bekendste maatregel om te voorzien in de herstelbaarheid is het implementeren van back-up- en recovery-procedures. o Degradatiemogelijkheid Het gemak waarmee de kern van de informatievoorziening kan worden voortgezet nadat een deel daarvan is uitgevallen. o Uitwijkmogelijkheid Het gemak waarmee (een deel van) de informatievoorziening op een andere locatie kan worden voortgezet.



Efficiëntie van de informatieverzorging Het gemak waarmee het systeem de informatie verstrekt (ongeacht de vraag hoe relevant die informatie is). o Snelheid van werken De snelheid waarmee het informatiesysteem transacties afhandelt.


40

o Gebruiksvriendelijkheid Het bedieningsgemak van het systeem voor de eindgebruikers. De inspanning om met het systeem te werken valt uiteen in een eenmalige inspanning: de inleertijd, en een permanente inspanning: de moeite die men moet blijven doen om het systeem te begrijpen bij het dagelijks gebruik. Het is duidelijk dat deze moeite kleiner wordt, naarmate de opzet van het systeem meer inzichtelijk is gemaakt, zodat de gebruiker het gevoel heeft dat hij het systeem bestuurt en niet andersom. o Zuinigheid De verhouding tussen het prestatieniveau van het systeem (uit te drukken in het transactievolume en de totale snelheid) en de hoeveelheid resources (CPU-cycles, I/O-tijd, geheugenbeslag, mensuren, enz.) die daarvoor verbruikt worden. o Aansluiting handmatige procedures De mate waarin de handmatige procedures van het bedrijf aansluiten op het geautomatiseerde informatiesysteem. o Werkbaarheid handmatige procedures De werkbaarheid van de handmatige procedures die behoren tot het systeem voor informatievoorziening. 

Effectiviteit van de informatieverzorging De mate waarin de informatievoorziening bijdraagt aan het bereiken van de bedrijfsdoelstellingen, die in het informatiebeleid onderkend en geselecteerd zijn. Een effectief informatiesysteem komt tot uiting in een verhoogde efficiëntie van de bedrijfsprocessen die het ondersteunt. o Dekkingsgraad bedrijfsprocessen Het percentage van de in het informatiebeleid onderkende en geselecteerde bedrijfsprocessen dat door het betrokken informatiesysteem wordt ondersteund, gewogen naar de frequentie en het belang van die processen. o Bruikbaarheid De mate waarin het informatiesysteem is toegesneden op de organisatie en het profiel van de eindgebruikers voor wie het bedoeld is. Het komt nog wel eens voor dat systemen niet met succes kunnen worden ingevoerd, omdat ze te moeilijk zijn voor de gebruikers. Berucht zijn in deze context de systemen die gebruik maken van metaconcepten, die op zichzelf de


41

ideale oplossing vormen voor gestelde flexibiliteitseisen, maar die het bevattingsvermogen van de uiteindelijke gebruikers verre kunnen overstijgen. o Ondersteuning besluitvorming De waarde die de informatievoorziening heeft als achtergrond en onderbouwing voor het vormen van beleid en het nemen van besluiten. Dit attribuut is bij uitstek van belang voor Decision Support Systems en Management Information Systems. o Ondersteuning eindgebruiker De mate waarin het systeem routinewerk van de gebruiker overneemt, zodat hij zijn creativiteit kan richten op de inhoudelijke aspecten van zijn taak.


42


43

Contact EXIN www.exin.com

Aanvullende onderwerpen ISyF

Recommend Documents