Hoofdstuk 4: Information Management Strategy

Doelstellingen van dit hoofdstuk:

Uitleggen waarom bedrijven nood hebben aan een informatie management strategie Het verband proberen te leggen met andere bedrijfsstrategieën Bespreken van management begrippen die ter sprake komen bij IMS

Informatie management strategie(IMS) is 1 van een reeks van strategieën die een onderneming toepast om hun positie in de markt te ondersteunen of te verbeteren. Deze reeks van strategieën bevat onder meer de organisatorische strategie,de marketing strategie en de operations management strategie.

Om het doel van IMS te begrijpen, moeten we dit vooral situeren binnen de context van de organisatorische strategie

Organisatorische strategie:

Definitie: Organisatorische strategie(corporate/organizational strategy) bepaalt de toekomstige richting en de handelingen de onderneming m.a.w. de aanpak en toewijzing van de middelen die nodig zijn om de doelstellingen te bereiken.

= lange termijn denken

De onderneming zal rekening moeten houden met:

De veranderende omgeving De markt=inspelen op de noden van de markt Stakeholders= proberen tegemoet te komen aan de verwachtingen van de

klanten,leveranciers,…

Kenmerken van organisatorische strategie:

Bepaalt de toekomstige richting van een organisatie Bedacht om een voordeel te behalen(tegemoet komen aan doelen) Toewijzing van middelen om het voordeel te bereiken Wordt gedreven door de noden van de organisatie en van haar stakeholders Is verantwoordelijk voor de veranderende omgeving waarin de onderneming werkt

Een aantal mogelijke organisatorische doelstellingen zijn:

Winst, efficiënt werken, effectiviteit, goede reputatie, goede service van de klanten,…

Deze doelstellingen verschillen naargelang de onderneming commercieel gericht is of de nadruk ligt op de diensten. (commercial – service organisations)

Informatie management stragetie(IMS):

IMS is 1 van de strategieën die de organisatorische strategie ondersteunt. Daarom is het nodig dat de IMS verbonden is met de organisatorische doelstellingen en uitlegt hoe informatiemiddelen moeten worden beheerd om zo de doelstellingen te bereiken.

1

Definitie: IMS bepaalt de aanpak van het management t.o.v. de organisatie, het controleren en toepassen van organisatorische informatiemiddelen d.m.v. coördinatie van mensen en technologische middelen met als doel de organisatorische strategie en processen te ondersteunen.

De verschillende ‘stages’ in een strategieproces

1. De huidige situatie analyseren2. De visie en de doelstellingen nauwkeurig formuleren3. Nadenken welke strategie het beste is om de doelstellingen te bereiken4. Nagaan op welke manier we de strategie gaan implementeren5. Het bijsturen en controleren van de strategie

Andere strategieën die de onderneming toepast zijn: marketing strategie, operations management strategie, Knowlegde strategie, IMS,….

Deze strategieën ondersteunen de organisatorische strategie

De verschillende vormen van strategie:

Om ervoor te zorgen dat een onderneming een effectieve ‘information management’heeft, zal ze verschillende strategievormen toepassen:

Information Management Strategy:

Deze strategie bepaalt de kwaliteit van de informatie, het informatiebeleid, de architectuur van de informatie en is bepalend voor wettige, ethische en beveiligingsaspecten

Knowledge Management Strategy:

Deze strategie stelt de kennis en bekwaamheden vast, bepaalt de technogische aanpak voor het Knowlegde management en bepaalt ook het informatiebeleid

Information Systems Strategy:

Deze strategie is nodig om de kwaliteit van de diensten te bepalen, de technologische infrastructuur en tenslotte ook nog te ontwikkeling van (nieuwe) toepassingen

Indien de aanpak van de Information management niet aangepast is, kan dat veel problemen veroorzaken. Vb. Een bedrijf verloor 30 klanten per dag omdat het personeel niet beschikte over de juiste informatie om aan de vereisten van de klanten te voldoen.

Daarom moeten ondernemingen voldoende aandacht besteden aan het IM en ook nauwkeurig analyseren wie verantwoordelijk is voor IM en welke de relatie is tot de andere managers( die verantwoordelijk zijn voor de strategie van informatiesystemen en de informatietechnologie alsook voor de Knowledge management strategie)

2

3

Extra uitleg:

Strategische problemen= gegevens die zeer sterk verwerkt zijn

Tactische problemen= gegevens die middelmatig verwerkt zijn

Operationele problemen= groot aantal gegevens die nauwelijks verwerkt zijn

Conclusie figuur: Hoe hoger het management, hoe meer de gegevens verwerkt moeten zijn.

Taak van managers in verband met IM:

In een bedrijf krijgen managers te maken met een grote hoeveelheid aan informatie(information overload).Het is dan de taak om de informatie te filteren en zo de juiste informatie eruit te halen.

Doel= de ondersteuning van het werk van het bedrijf

Hoe gebeurt dit?

- Door het beheer van informatie te verbeteren- Effectievere en efficiëntere uitwisseling van informatie met externe

personen/bedrijven

Wordt er veel belang gehecht aan IMS?

4

De laatste jaren krijgen bedrijven steeds meer het besef dat information management zeer belangrijk is in een bedrijf.

IMS= belangrijk kapitaal

Binnen het luik van IMS, kunnen we nog een aantal thema’s onderscheiden:

1. De waarde van informatie(= Information Value) Strategische informatie= informatie van de hoogste waarde , vb. doelstellingen,

prestatiemeters,…Ook externe informatie valt hieronder, vb. informatie over de markt

Zeer belangrijke informatie(high potential)= deze informatie is belangrijk voor de onderneming maar staat nog niet volledig vast. Vb. KM: beoordelen/waarderen van de informatie en nagaan of het mogelijk/goed is om er strategische informatie van de maken in de toekomst

Operationele informatie= de waarde van deze informatie wordt versterkt door de horizontale integratie. Een zeer groot aantal gegevens behoort tot deze categorie, vb. verkoop, klantengegevens,… De waarde van deze gegevens voor de toekomstige strategie van de onderneming=beperkt maar ze zijn wel van belang voor het invoeren/toepassen van de huidige strategie

Ondersteunende informatie= deze gegevens zijn nodig om de werking van een onderneming te ondersteunen maar hebben slechts weinig strategische waarde. Vb. informatie over het personeel, tijdschema’s,…

2. De kwaliteit van informatie(= Information Quality)

Hoe kan ik de kwaliteit van de informatie waarborgen? Hiervoor worden verschillende beoordelingscriteria gebruikt:

Inhoud:-Nauwkeurigheid(accuracy)-Relevant(Relevance)-Completeness(volledig)-Beknopt(Conciseness): niet te gedetailleerd-Draagwijdte(Scope)

Tijdsdimensie:- ‘timeliness’ = beschikbaar wanneer men de informatie nodig heeft- looptijd (currency): up- to- date-Frequentie-tijdsperiode

Vorm/structuur- duidelijkheid(clarity)-Detail(Detail): zowel een korte samenvatting als de volledige gedetailleerde gegevens-Gerangschikt(order)-Presentatie(presentation): tabellen of grafieken-Media: ‘hard copy’ (kopieën) en ‘soft’ copy( elektronisch opgeslagen en toonbaar)

3. De beveiliging van informatie(= InformationSecurity) Het beleid van de beveiliging De organisatie van de beveiliging Controle van de activa

5

Personeelsbeveiliging…

4. De wettelijke en ethische aspecten(= Legal and ethical compliance)

Vbn. Van privacy kwesties: het verzenden van een ongevraagde e-mail naar een klant

Of controleren van de toegang van werknemers tot data en onlineservice

5. Kennis management(= Knowledge management)

Taken van managers binnen deze categorie:

- Nagaan hoe we de kennis moeten gebruiken om de efficiëntie van de onderneming kunnen verbeteren

- Nagaan hoe de ICT de KMS ondersteunt- Welke verbintenis bestaat er tussen KMS en bedrijfsstrategie

In grote ondernemingen, vb. managementadviesbureau, is het nodig om een gescheiden KMS te ontwikkelen. KM= belangrijke bijdrage voor een effectieve onderneming

In kleine ondernemingen verwijst IMS naar de ondersteuning van de KMS

Technologische ondersteuning(= technology support)

Belangrijke taken van managers binnen deze categorie:

- Nagaan welke verbintenis er bestaat tussen IS(information systems) strategie en de bedrijfsstrategie

- Nagaat wie binnen de organisatie verantwoordelijk is voor de IS strategie- Nagaan hoe de onderneming de effectiviteit van IS strategie kan controleren en

evalueren

Verschillende aanpakken van IMS:

1. Structurering van de IM functie:

Definitie information management unit= Een organisatorische eenheid verantwoordelijk voor de IMS binnen een organisatie. Een IM unit richt zich op de verbetering van IM.

In kleine ondernemingen: IM unit= één persoon die voltijds of halftijds werkt aan de IM. Die persoon zal samenwerken met andere managers. Om de beste resultaten te bekomen, zal deze functie vooral toegekend worden aan een ‘senior manager’ zoals de financieel directeur of de IT manager.

In grote ondernemingen:IM unit= kleine afdeling of een team van mensen

Taken van die groep:

- de ontwikkeling en invoering van de IMS

- zich bezig houden met zaken die verband houden met informatie zoals het beleid van de bescherming van gegevens(data protection policy)

- trainen/opleiden van het personeel

6

2. Verantwoordelijkheden en training: Governance responsibility: managers die verantwoordelijk zijn voor het totale beheer

en de controle van IM Stewardship responsibilities: Informatie beheerders zijn verantwoordelijk voor de

kwaliteit van de informatie en dit houdt ook veschillende activiteiten in zoals het behouden en creëren van infomatie, de verspreiding en verwijdering van informatie

Infrastucture responsibilities: het creëren van de juiste omgeving voor het gebruik van informatie. => technische rol

Usage responsibilities= de verantwoordelijkheid van de eindgebruiker van informatie. Behalve het gebruik van informatie, bevat deze functie ook nog het beoordelen van informatie inzake de kwaliteit.

3. Analyse van de informatie middelen:

information audit= evaluatie van het gebruik van informatie en informatiestromen in een organisatie

Doel van informatie audit: op zoek gaan naar de huidige en potentiële gebruikers van informatie, de kwaliteitsvereisten van deze gebruikers nagaan, de verschillende types van informatie nagaan, …

Informatie ‘mapping’= een aanpak voor de identificatie van de waarde van en de relaties tussen informatiemiddelen

Doel = identificatie van kritische informatiemiddelen en van informatie met buitengewone waarde

Het wordt ook gebruikt wanneer er nood is aan toepassingen om de middelen beter te beheren.

4. Risico management(Risk Management):

Risico management wordt gebruikt voor de identificatie van mogelijke risico’s die voorkomen in een reeks van situaties en acties ondernemen om die risico’s te minimaliseren.

potentiële risico’s worden geëvalueerd en dan worden er strategieën ontwikkeld om de risico’s te verminderen en het inschatten van toekomstige risico’s.

Risico management gebeurt in vier stappen:

de identificatie van de risico’s + de kans dat het risico zich voordoet +impact zoeken naar mogelijke oplossingen implementeren van de oplossingen om de risico’s te bestrijden die de grootste impact

zullen hebben en waarvan de kans groot is dat ze zich voordoen de risico’s controleren om in de toekomst de risico’s goed/beter te kunnen beroordelen

Waarom is een IMS nu nodig?

Er kunnen verschillende organisatorisch problemen ontstaan in verband met de slechte kwaliteit van de gegevens:

Vb. slechte klantendienst, de informatie kan niet gebruikt worden om waarde te creëren, de informatie leidt tot het nemen van verkeerde beslissingen,…

7

Wat zijn de gevolgen van slechte IMS?

Vbn.

-Verlies van een groot aantal klanten per dag omdat het personeel geen toegang had tot de juiste informatie om de klanten te bedienen/helpen.

- tegenstrijdige informatie tussen verschillende systemen => dezelfde gegevens moeten in meer dan 1 systeem zijn ingegeven

Problemen in verband met de kwaliteit van de gegevens:

Voordelen van IMS:

- Er bestaat nu de mogelijkheid om alle activiteiten die informatie bevatten te verenigen tot 1 geheel en de informatie snel en effectief te gebruiken om de efficiënte bedrijfsbeslissingen te nemen

- Promoten van goede/open communicatie binnen het bedrijf- Zal leiden tot een reeks van innovaties en kennisuitwisseling- Vormt een goede strategie voor de investering in informatiesystemen en technologie- Verzekert de aandachtigheid van de kansen en bedreigingen binnen het bedrijf en laat

toe om deze op tijd te beantwoorden

De verantwoordelijkheid voor middelen die betrekking hebben op informatie:

De managers moeten goed op de hoogte zij wie verantwoordelijk is voor het beheren/ voorzien van informatiediensten die externe informatie leveren. Ze moeten ook goed weten wie de informatie beschermt en wie de richtlijnen levert in verband met de kwaliteit van de informatie.

8

Er zijn 2 verschillende perspectieven om informatie te beheren:

1. Technology-led approach2. Information-led approach

Richtlijnen van het ‘Hawley Committee’ verslag:

Achtergrondinformatie:

Hawley Committee = opgericht in 1994

Doel= advies geven over hoe informatiemiddelen moeten beheerd worden in een onderneming

Er waren 2 hoofdthema’s:

Thema 1 gaat over hoe een ondernemingen zijn informatie management kan gebruiken om zo de operationele capaciteit en dus de waarde van de aandeelhouders te vergroten

Vb.

- het winnen van meer grote contracten door het combineren van gedetailleerde informatie van de onderneming en de leveranciers

- Het versterken van de dienst na verkoop doordat de onderneming in staat is de aankopen van klanten en de geschiedenis inzake de service van de klant te identificeren.

Thema 2 gaat over de mogelijke problemen die een slechte IM kan veroorzaken.

Vb.

- Een juridisch geschil tussen 2 bedrijven over het feit dat de ene onderneming informatie over de andere onderneming verkeerd heeft gebruikt, kost=miljoenen

- Het uitlekken van een banksysteem in verband met een screenen van de kredietwaardigheid van klanten

Het rapport van het Hawley Committee is gericht op de verantwoordelijkheden van de raad van bestuur binnen de onderneming inzake IM

De raad zou zichzelf tevreden mogen stellen indien hun onderneming zo geleid wordt dat:

Informatie enkel gebruikt wordt waarvoor het dient De raad zich bewust is van, en goed geadviseerd wordt over de informatie betreffende

alle zaken in zijn agende Het gebruik van informatie(door de raad zelf) door rekening te houden met juridische,

ethische,.. aspecten

De raad moet het beleid van de onderneming bepalen in verband met de informatiemiddelen en moet controleren of de onderneming het beleid ook toepast. Dit houdt in:

Bescherming van informatie tegen misbruik,diefstal,…

9

Strategie voor de informatiesystemen en de implementatie ervan Opleiding/training van mensen om informatie goed te beschermen en de

informatiemiddelen(activa) goed te beveiligen Zelf informatie gebruiken door rekening te houden met de wetgeving en ethische

kwesties Het aanwenden van informatieactiva Ervoor zorgen dat de kwaliteit en hoeveelheid informatie beschikbaar is wanneer

nodig,betrouwbaar is,… en dit voor elke afdeling van de onderneming De identificatie van de informatieactiva en de indeling ervan volgens waarde,

Orna’s informatie beleid en informatie audit:

= richtlijn/gids voor ondernemingen om zo hun informatie management te verbeteren

Definitie van IM volgens Orna:

IM heeft te maken met:

De manier waarop informatie verzameld wordt,geregistreerd en opgeslagen de plaats waarde informatiemiddelen gevestigd zijn in de onderneming en wie er

verantwoordelijk voor is de manier waarop informatie stroomt binnen de organisatie en tussen de organisatie en

de buitenwereld de manier waarop de onderneming de informatie gebruikt de manier waarop de mensen die gebruik maken van informatie hun vaardigheden

gebruiken en samenwerken met elkaar de manier waarop informatie technologie de gebruikers ondersteunt/helpt de kost en waarde van informatie de manier waarop alle activiteiten die met informatie te maken hebben met elkaar

verbonden zijn en bijdragen tot het realiseren van de doelstellingen

Informatie beleid(information policy) is een groot hulpmiddel voor bedrijven bij de verbetering van de informatie management

= stelling van de aanpak van de ondernemingen betreffende informatie management

Het informatiebeleid ondersteunt de strategie door de onderneming te voorzien van de doelstellingen van IM, maar zal ook meer gedetailleerde richtlijnen geven op personeelsverantwoordelijkheden. Vb. uitleg geven aan het personeel over hoe zij informatie moeten gebruiken

Kenmerken van informatiebeleid:

tamelijk korte stellingen/beweringen is het resultaat van voorbereidend werk voldoende sterk om te blijven(het is geen gedetailleerde actieplan)

Deze kenmerken hangen af van de informatiestrategie en kunnen dus ook enorm verschillen. I

Informatie strategie(information strategy)

= een plan met daarin de doelstellingen van informatie management en het bijhorende tijdschema, de taktieken en de controles om deze doelstellingen te bereiken

10

Informatie audit(information audit)

= een evaluatie van het gebruik van en de informatiestromen binnen een onderneming die de bedrijgfsdoelstellingen ondersteunen

Het ‘Willard’ model: informatiemiddelenmanagement(IRM)

Het Willard model beschrijft 5 elementen van IRM(= information resource management)

1. Identificatie: de ontdekking van informatiemiddelen en de vastlegging van de kenmerken in een inventaris/register

2. Bezit/eigendom: verantwoordelijk zijn voor het onderhouden van de informatiemiddelen

3. De kost en de waarde: de beoordeling van de kosten van de informatiemiddelen + waarde voor de onderneming

4. Ontwikkeling: de verdere ontwikkeling van informatiemiddelen om zo de waarde die het toevoegt aan de organisatie te verhogen

5. Exploitatie: het proces dat ervoor zorgt dat een hulpmiddel(resource) meer waarde kan genereren d.m.v. omzetting in een goed of een verkoopbaar artikel

Hoofdstuk 5: Knowledge management strategy

Knowledge management is voor het eerst opgedoken in 1990.

Indien een onderneming het leerproces beter kan beheren, dan kan ze efficiënter worden

KM strategy, definitie :

= plan van acties om zo te zorgen dat de ‘core business’( kern van het bedrijf, kernactiviteiten) goed werkt door gebruik te maken van kennis management technieken

11

Uitleg:

Eerst en vooral is het nodig om te begrijpen hoe de kennis de bedrijfsprocessen en de doelstellingen ondersteunt, daarna moet de onderneming de kennis proberen te classificeren/ordenen. De volgende stap is de identificatie van de strategie aanpak + implementatie van die strategie. Een strategie moet meetbaar zijn omdat het nodig is om feedback te kunnen geven en zo de kwaliteit van de kennis te verbeteren en de ROI(return on investment, rendement op eigen vermogen) te beoordelen.

Definitie van data, kennis, informatie:

Data= discrete; objectieve feiten(nummer,symbolen,figuren) zonder context of interpretatie

Informatie= de basis voor kennis

= gegevens die waarde toevoegen aan een voorwerp en hier is de context wel van belang

Kennis= de combinatie van data en informatie met toevoeging van een deskundige mening, vaardigheden en ervaring om zo te resulteren in een waardevolle activa die kan dienen als hulp bij het maken van beslissingen.

Kennis kan expliciet of impliciet zijn, individueel of collectief

Het verband tussen deze drie begrippen wordt verduidelijkt aan de hand van de volgende figuur:

12

Het model van de expliciete/impliciete kennis:

Stilzwijgende(tacit) kennis= kennis die verband houdt met ervaring (subjectief)

Expliciete (explicit) kennis= rationele en sequentiële kennis (objectief)

Verschillende processen waar kennis is ontstaan en overgedragen:

Van Stilzwijgend naar stilzwijgend: dit gebeurt doorheen een socialisatieprocesVb. de marketing manager discussieert met de verkoopsdirecteur over de laatste trends

Van stilzwijgend naar expliciet doorheen een belichamingprocesVb. de verkoopsdirecteur verzendt een e-mail met daarin zijn gedachten/mening over hoe de nieuwe prijsstructuur zou moeten zijn/veranderen

Van expliciet naar stilzwijgend doorheen een proces van internationalisering(z’n eigen maken)Vb. de marketing manager leest en begrijpt de verslagen om een nieuw inzicht en begrip te krijgen in de situatie

Van expliciet naar expliciet doorheen een combinatieprocesVb. de marketing manager combineert kennis van verslagen die geproduceerd zijn door databases om zo een overzicht te kunnen maken van de huidige situatie

Dit moet je bekijken als een bruikbaar instrument, niet als een volledig model.

13

Figuur: Nonaka’s tacit/explicit model:

Andere definities :

Kennis in termen van functies:

- Verklarende kennis(declarative)= kennis over iets- Kennis betreffende een procedure (procedural)= know-how- Oorzakelijke kennis= kennis over het ‘waarom’- Voorwaardelijke kennis= kennis over het ‘wanneer’- Relationele kennis

Blacker zegt dat er vijf beelden zijn van kennis:

1. Embrained knowledge= afhankelijk van conceptuele en cognitieve vaardigheden2. Vormgevende kennis( embodied)= actie-gericht en is slechts gedeeltelijk expliciet3. Vastliggende kennis(embedded)= kennis dat terug te vinden is in systematische

routines4. Gecodeerde kennis(encoded)= informatie die is overgebrachte door middel van tekens

en symbolen5. Encultured knowledge =proces van het bereiken van gedeelde begrippen

Knowledge management SWOT:

SWOT analyse = Streghts(sterke punten), Weakenesses(zwakke punten), Opportunities(kansen), Threats(bedreigingen)

14

De analyse houdt in:

Nagaan welke gebieden van de ondernemingen voordeel haalt uit de waardevolle kennis

Nagaan welke gebieden een gebrek hebben aan kennis Nagaan of er mogelijkheden zijn om de kennis te beheren/exploiteren Nagaan welke competitieve bedreigingen er zijn voor de kennis waardoor het zijn

waarde verliest

De analyse voor KM strategie:

Nagaan wat de ‘kern’ aspecten zijn van de onderneming Nagaan of er verandering plaatsvinden Nagaan hoe de concurrentie zich proberen te onderscheiden op de markt

De knowledge audit:

Definitie: de kennis audit is een systematisch proces van identificatie van activa die te maken hebben met kennis en de relatie van die activa doorheen de organisatie

Wat is het doel van een ‘knowledge audit’?

- Identificatie van middelen die zorgen voor de creatie en innovatie van de kennis- Biedt zo de kans om de beoordelingen van de huidige organisatorische kennisbasis te

documenteren (op een geformaliseerde manier)- De beoordeling van de impact van de kennis van de klant/leverancier- De beoordeling van de factoren die het uitwisselen/delen van kennis met anderen

aanmoedigt- Identificatie van de factoren die het uitwisselen van kennis verbieden- …

Verband/verschil tussen kennis audit en informatie audit:

Informatie audit Kennis audit= gericht op informatieobjecten = gericht op personen

Concentreert zich op de knowhow van de werknemers en de kennisstromen

Knowledge maps:

= visuele voorstelling van de activa van een onderneming die verbonden zijn met kennis, van de kennisstromen en van de relaties.

SNA= Sociaal netwerk analyse

= het in kaart brengen en meten van de relaties en de ‘stromen’ tussen mensen, groepen, bedrijven, computers of andere entiteiten die te maken hebben informatie/kennis processen.

De knooppunten in het netwerk zijn de personen en groepen

15

De verbindingen(links) stellen de relaties of stromen voor tussen de knooppunten.

= visuele en wiskundige analyse van menselijke relaties.

Gap analyse:

Er zijn twee soorten:

1. Kennis kloof(knowledge gap)= het verschil tussen wat de onderneming moet weten en werkelijk weet

2. Strategische kloof(strategic gap)= het verschil(kloof) tussen wat de onderneming moet doen en wat ze kan doen.

Het gebruik van informatie en communicatietechnologie(ICT) dat nodig is voor de ‘vestiging’ van kennis management:

Kenmerken/eigenschappen van ICT:

ICT op zich kan kennis NIET beheersen ICT kan toegang voorzien tot de juiste verzameling van gegevens en informatie ICT zou de werkers in staat moeten stellen kennis te creëren, te delen en over te

dragen

ICT mogelijkheden:

Intranet (= een gesloten intern netwerk gebaseerd op Internet en World wide web Technologies)– extranet(= een gebied van een intern netwerk dat opengesteld is voor klanten die er wettelijk toegang tot hebben en partners, gebaseerd op www technologies)

Deskundige databasen Gezamelijke hulpmiddelen(tools) CRM= customer relationship management …

Informatiesystemen strategie(IS strategy)

Definitie: IS strategie= plaatsen van relatieve investeringsprioriteiten voor toepassingen, ondersteuningsdiensten en infrastructuur.

De infrastructuur bestaat uit hardware, netwerk architectuur, informatie architectuur en informatie management

Strategische informatie: men moet nagaan wat de huidige status is van de informatie IS strategie, de implementatie ervan binnen de onderneming en het gebruik van informatiesystemen rekening houdend met de competitieve omgeving

Strategische doelstellingen: nagaan wat de onderneming precies zoekt om de doestellingen te bereiken d.m.v. de ontwikkeling van IS strategie

Definitie van strategie: nagaan welke strategische aanpakken en hulpmiddelen beschikbaar zijn. Deze kunnen helpen bij de formulering van de IS strategie

Implementatie van de strategie: nagaan hoe de strategie het best kan worden uitgevoerd doorheen de IS projecten om zo de doelstellingen helpen te bereiken

16

Kenmerken/elementen van een effectieve IS strategie

Het moet de toekomstige richting van een onderneming sturen Het moet een voordeel bieden voor de onderneming IS strategie moet ervoor zorgen dat de middelen goed worden toegewezen om zo het

voordeel te kunnen bereiken De IS strategie moet hoofdzakelijk gedreven zijn door de noden van de organisatie

maar ook door de noden van de shareholders, de klanten, de leveranciers en de werknemers

IS strategie moet rekening houden met de veranderende omgeving waarin de onderneming zich bevindt

De opbrengst/resultaat(outputs) van een IS strategie proces

IS/IT management strategie: een totale IS strategie voor het bedrijf om de huidige situatie te beschrijven, de visie en de basis voor plannen die betrekking hebben tot de IS.

Bedrijfs IS strategieën: in grote ondernemingen, deze strategieën geven meer uitleg over hoe elke bedrijfseenheid de IS en IT moet gebruiken om zo de doelstellingen te realiseren. Dit gebeurt aan de hand van bedrijfsportfolio’s en relevante informatie architectuur.

IT strategie= het beleid voor het management over specifieke hardware en software die de IT samenvatten. Het bevat ook de voorziening van de ondersteuningsdiensten voor de eindgebruiker vb. IT help desk

Vereisten van IS strategie:

Zorgen voor de verbinding van IS strategie en bedrijfsstrategie. Ondertussen moeten ook de prestatiegerichte mogelijkheden die beschikbaar zijn in de IS worden geïdentificeerd.= de twee kerndoelstellingen van IS strategie

Eenvoud door goed bepaalde stages. Het proces zou moeten beschikken over duidelijke, herhaalbare stappen van stages die kunnen uitgevoerd worden in een logische volgorde.

De eenvoud zal ervoor zorgen dat senior bedrijfsmanagers samenwerken met technische IT managers om zo de strategie te ontwikkelen

Een continu proces waar ook rekening wordt gehouden met de evaluatie ervan en eventuele verbeteringen. Het zou moeten worden herkend doordat het een herhaalbaar proces is dat de sterke en zwakke punten evalueert op het einde van elke planningcyclus en aanpassingen doorvoert.

Flexibiliteit: het proces zou in staat moeten zijn om veranderingen in de bedrijfsomgeving te weerspiegelen in de IS plannen.

De draagwijdte van IS strategie:

Tijdschaal:- Lange termijn: 2-5 jaar- Korte termijn: 6 maanden tot 1 jaar Oriëntatie:- Van boven naar beneden: top-down

17

- Van beneden naar boven: bottom-up

De mogelijkheden op de IS en IT te controleren:

1. Het aanstellen van een IS/IT directeur2. Andere leden van de raad die verantwoordelijk zijn voor de IS en IT3. Het sturen van het comité of de speciale werkgroep4. Een ‘business unit leader’

Inzicht in onderzoek:

18

Waarschijnlijk zul je in je toekomstige carrière wel eens in aanraking komen met ‘system’ development:

Als een werknemer wiens job gereorganiseerd wordt

Als deel van een team (Bv. als analyst) dat betrokken is in de ontwikkeling van een nieuw systeem

Door een bestaand systeem aan te passen

Doordat je verantwoordelijk bent om de vereisten voor een nieuw systeem te specifiëren.

19

» Alle groepen zijn evenredig

» De analist is wel één persoon, maar er zit wel een heel team achter !

Doelstellingen:

De doelstellingen van ‘ system development’ bestaan erin om gepaste technieken te bepalen voor het designen en implementeren van informatiesystemen. Ook wil men gepaste controle bepalen om risico’s die eigen zijn aan informatiesysteem- ontwikkelingsprojecten te beheren.

Wat je moet kunnen:

De identificatie van typische stadia in een informatiesysteemproject. De identificatie van de risico’s die verbonden zijn aan de stadia in een project. Het begrijpen van de benaderingen die projectmanagers gebruiken om hun

projecten te beheersen. Het ontwikkelen van een DFD, ERD en UML diagram om het

informatiesysteem te ontwerpen. Het ontwerpen en programmeren van kleine problemen in ‘ Visual Basic’.

Typische vragen die managers zich stellen:

Hoe kan je vermijden dat de ontwikkeling van een informatiesysteem faalt? Welke specifieke risico’s zijn verbonden aan het beheer van informatie-

managementprojecten?

Informatiesysteem

Een informatiesysteem is een speciale soort systeem dat een overkoepeling vormt voor hardware, software, data, mensen en procedures die onafhankelijk van elkaar functioneren vermits enige controle. Op deze manier worden gegevens verwerkt en wordt informatie beschikbaar voor gebruikers. De uiteindelijke bedoeling hiervan is uiteraard om dagelijkse operaties in een bedrijf (= dataprocessing) te ondersteunen en te verbeteren. Daarnaast wil men via informatiesystemen ook probleemoplossing en het nemen van beslissingen voor het management van een bedrijf, verbeteren.

20

Het beheer van systeemontwikkeling

In deze tabel zie je verscheidene projecten die uiteenlopende project management methoden gebruikten. Dit betekent dat de reden voor mislukking niet uitsluitend bij de projectmanager ligt, maar dat een hele hoop managers en werknemers samen verantwoordelijk zijn.

Een project kan geslaagd, gedeeltelijk gefaald of compleet gefaald zijn:

* Geslaagd: Het project was tijdig en binnen het vooropgestelde budget afgerond, waarbij alle vereiste kenmerken en specificaties ook aanwezig zijn.

21

* Gedeeltelijk gefaald: Het project is afgerond, maar viel buiten het geplande budget, was niet tijdig af and mist enkele vereiste kenmerken en specificaties.

* Compleet gefaald: Het project werd afgelast en was dus niet afgerond of zelfs nooit geïmplementeerd.

Een niet uithoudbare situatie:

Enerzijds:

- Mensen maken informatiesystemen waarbij ze geen specifieke methode gebruiken.

- Men maakt vaak fragiele informatiesystemen

- Men maakt vaak geen accurate informatiesystemen

- Informatiesysteemontwikkeling is heel duur + vraagt veel planning en moeite

Anderzijds:

- Er komen steeds nieuwe modelleertechnieken waardoor je kleine stukjes van een systeem bouwt en die aan elkaar koppelt (prototyping)

- De vraag naar informatiesystemen stijgt elke dag

- De meeste mensen vertrouwen heel vaak bewust of onbewust op software en informatiesystemen voor het merendeel van hun sociale activiteiten.

Beperkende voorwaarden voor IS project management

In het beheer van ontwikkelingsprojecten voor applicaties, is er een balans tussen ‘ Beperkende voorwaarden op applicatiekwaliteit’ en ‘Beperkende voorwaarden op projectmanagement’.

22

Als de applicatie/toepassing bijkomende kenmerken nodig heeft om verdere behoeften van het bedrijf of andere gebruikers te bevredigen dan diegene die op voorhand bepaald waren, dan zijn er meer projectbronnen nodig. Deze projectbronnen zijn onder andere: de tijd die mensen besteden aan het opbouwen van het systeem, software, hardware, enz. Een alternatief is om nieuwe kenmerken te ontwikkelen door af te bouwen op andere kenmerken.

De beperkende voorwaarden op applicatiekwaliteit, zorgen voor de nood aan:

* bedrijfswinst

* informatiekwaliteit

* een goede beoefening

* een goede stabiliteit

De beperkende voorwaarden op projectmanagement zijn:

* De duurtijd voor een project

* Het werk dat er in een project gestoken moet worden

* De bronnen voor een project

* Het voorziene budget voor een project

23

Een opdrachtgever zal vaak in woorden uitleggen wat hij nodig heeft in het systeem. De persoon die het systeem uittekent is dan iemand die zich in de problematiek moet kunnen inwerken. Ook moet deze persoon foute communicatie en verwerking ervan in de gegevens opsporen.

In de bovenstaande afbeelding interpreteren alle communicatiepersonen( zoals de klant, projectleider,analist, programmeur,...) de oorspronkelijke wens van de opdrachtgever fout (= eerste prentje). Als gevolg hiervan is het resultaat absoluut verkeerd. Het heeft immers niets meer met de gevraagde ‘schommel’ te maken.

De software crisis

- De spanning die gecreëerd werd door tegenstrijdige belangen zorgde ervoor dat er een software crisis ontstond, dewelke zijn hoogtepunt kende in eind de jaren 70 tot en met begin de jaren 80.

- De software crisis zorgde er op den duur voor dat informatiesystemen niet meer als een geheel functioneerden door :

* Fouten ivm de kosten bij de ontwikkeling van grote systemen

* Problemen met het behoud van bestaande systemen

* Ontwikkelingen in hardware

*De gebruikers/ cliënten wilden steeds meer, betere en goedkopere software.

- De gevolgen van deze crisis zijn nog steeds merkbaar door bijvoorbeeld het feit dat softwareontwikkeling nog altijd achterloopt op hardwareontwikkeling.

Eigenlijk moet je er dus voor zorgen dat je de noden eenvoudig en visueel in kaart brengt om deze dan te gebruiken in informatiesystemen !

Maatregelen voor succes

We weten reeds dat een IS project slechts volledig succesvol is wanneer het op tijd geleverd wordt, binnen budget en aan de behoeften van de gebruiker of het bedrijf voldoet. Toch zijn er tegenwoordig vaak nog zeer veel fouten en kosten die samenhangen met IT projecten, waardoor het veel belang gehecht wordt aan ‘maatregelen tot succes’ ( KPMG onderzoek) :

* Tegemoetkomen aan de behoeften van het bedrijf ( 46%)

24

* Tijdige levering (21%)

* Binnen budget (9%)

* De 3 voorgaande maatregelen samen (24%)

3 kritische succesfactoren in projectmanagement:

1. Tegemoetkomen aan de ‘ system requirements’ of ‘systeemvereisten’

= De definitie van hoe een IS zal worden gebruikt binnen de onderneming door onder andere het geven van gedetailleerde kenmerken of specificaties. Vaak zijn er communicatieproblemen hieromtrent.

2. Controle over veranderingen in vereisten (= requirements creep).

Vaak zullen de vereisten van een bedrijf tijdens het project veranderen, aangezien er vaak nieuwe kenmerken ontdekt worden die het succes van een bedrijf verbeteren. Soms blijkt ook dat oorspronkelijk voorgestelde kenmerken niet meer nuttig zijn.

Requirements creep = Geleidelijke veranderingen in de specificatie van een IS project gedurende de implementatie ervan.

3. Intregration risk of integratierisico

= Het project kan overbelast geraken door het feit dat er extra werk optreedt wanneer de output van de verschillende activiteiten binnen het project samengevoegd en geïntegreerd moeten worden.

Niet- systematische benaderingen in het verleden

Vroeger lag de nadruk op het vinden van een oplossing voor het probleem van de gebruiker. We weten ook dat efficiëntie gelijk is aan het juist uitvoeren van een taak, terwijl effectiviteit gelijk is een de juiste taak uitvoeren. Met andere woorden, men moet manieren vinden om het bedrijf van onze gebruiker te onderzoeken en te begrijpen en daarbij ook hun problemen identificeren. Op deze manier kan men de juiste oplossing vinden voor het juiste probleem. Zo gaat men geen Informatiesystemen meer ontwikkelen die een mengeling zijn van aangekochte én zelf ontworpen stukken, maar zal men zich echt richten op de echte problemen van de gebruiker en hiervoor een oplossing vinden.

25

Einde van de jaren 60’:

Output georiënteerde methodes:

Je had bijvoorbeeld de programma’s factureren, verkoopsanalyse, voorraadbeheer,enz. Deze werden dan aan elkaar gekoppeld en beschouwd als een informatiesysteem.

De jaren ’70

In de jaren 70 ontstond het concept van de Life cycle naar boven, welke de ‘Systems Development Life Cycle’ genoemd wordt. Deze methode loopt doorheen de gehele levensduur van een systeem en baseert zich op 6 verschillende fases die een project doorloopt, namelijk:

1. Initiatie: Dit is de opstartfase waarbij men vaststelt waarom en hoe het systeem ontwikkelt moet worden. Men voert hier haalbaarheidsonderzoeken uit (= feasibility study) en stelt projectplannen op.

Voorbeeld voor haalbaarheidsonderzoek : onderzoeken of een voorraadbeheersysteem haalbaar is.

26

2. Analyse: Gedurende deze fase zal men de behoeften en vereisten van de onderneming en systeemgebruikers bepalen. Wat zijn hun noden?

3. Design/ontwerp: In deze fase bepaalt men hoe het systeem vorm zal krijgen, waarbij men ontwerpopties voor de creatie en integratie van onderdelen voor het systeem evalueert.

4. Programmering: Het ontwerp wordt geïmplementeerd door programmeurs.

5. Implementatie: De installatie en het testen van het systeem of het overschakelen van een oud naar een nieuw systeem. Het systeem wordt beter gezegd in het bedrijf gebruikt en de efficiëntie ervan wordt nagegaan.

6. Onderhoud/maintentance: In deze fase wordt het systeem gemonitord en bewerkt om het vlot te doen verlopen en zelfs te verbeteren. In deze fase kunnen ook allerlei problemen opduiken.

Aan zulk een benadering met fases zijn enkele voordelen verbonden:

* Benchmarking: men kan verschillende systemen met elkaar vergelijken

* Beter inzicht

* Er ontstaat een kader waarrond documentatie opgebouwd kan worden

* Er ontstaat een definitief voorruitgaande aaneenschakeling of keten

* mogelijkheden voor ‘prototyping’

* meer participatie van de eindgebruiker of klant

* mogelijkheden voor betere teststrategieën

*…

Development process methods

Er zijn verscheidene ontwikkelingsmethoden, namelijk:

- System development life cycle / systeem ontwikkelingslevenscyclus- Waterval en verrijkte waterval(= enhanced waterfall)- V-model- Evolutionairy prototyping ( = incrementeel)- Throw-away prototyping (= vluchtig)- Rapid Application Development ( RAD)- Spiraal- Reuse oriented

27

Men is de methodes altijd maar gaan aanpassen om beter op de behoeftes van de gebruikers in te kunnen spelen.

De selectie van het geschikte model is uiteraard zeer belangrijk voor het project. Men kan ook een mengeling gebruiken

1.The waterfall model of system development

In de jaren 50’-70’ ontwikkelde er zich het waterval model, waarin de 6 fases van systeemontwikkeling of softwareontwikkeling elkaar opvolgen, hoewel er enige overlapping tussen de fases mogelijk is.

Er kunnen tijdens de intiatiefase bijvoorbeeld ook al voorbereidende analyses of design uitgevoerd worden. Het is ook mogelijk dat men teruggrijpt naar voorgaande fases.

De voornaamste eigenschap van dit model is dat wanneer men het uittest, er regelmatig nog problemen of nieuwe vereisten opduiken. Vaak moeten de analyse, design en ontwikkeling bijgevolg herhaald worden. Bij elke stap is er dus een terugkoppeling mogelijk. In het waterval model kan elke fase ook maanden en zelfs jaren duren alvorens deze afgerond is. Vaak doet er zich toch vooruitgang/ progressie voor van de ene fase naar de andere zonder dat er een probleem opduikt. Vandaar de naam ‘waterval model’; de ontwikkeling loopt regelmatig vloeiend naar beneden(als een waterval).

Geschiktheid:

Het waterval model is geschikt indien de vereisten duidelijk geformuleerd zijn en aanpassingen aan het model gedurende het design proces gelimiteerd kunnen worden.

28

Nadelen aan het waterval model

* Het grootste nadeel dat samenhangt met het waterval model is uiteraard het feit dat elke fase afgesloten moet zijn alvorens men overgaat op de volgende fase. Dit zorgt uiteraard voor grote vertragingen in de ontwikkeling van het systeem. Beter gezegd: met het waterval model is het alles OF niets.

* Late feedback:

De enige rol van de gebruikers is om de vereisten duidelijk op voorhand te bepalen. Gebruikers worden daarna eigenlijk enkel betrokken in de analyse- en implementatiefase, waardoor ze geïsoleerd zijn van het ontwikkelingsteam. Hierdoor wordt er nooit verder gediscussieerd over verdere problemen, fouten, tekortkomingen,… Door dit gebrek aan feedback van de gebruikers naar de ontwikkelaars en andersom, zullen er zich frequent problemen voordoen en zal men het proces nog opnieuw moeten herhalen, wat veel tijd in beslag neemt.

* Minimaal risicomanagement.

* Late test maturity

2. Het incrementele model

Het incrementele model is eigenlijk een combinatie van prototyping en het waterval model.

[ Prototyping is een benadering voor de ontwikkeling van informatiesystemen die de problemen in verband met het waterval model goed aanpakt.

Een prototype is een voorafgaande versie van een gedeelte of het geheel van alle informatiesystemen, dewelke gecontroleerd en bekritiseerd wordt door de gebruikers en bedrijfssponsors ].

Het incrementele model:

29

* Het incremental model is een methode voor softwareontwikkeling waarbij het model op een incrementele manier wordt ontworpen, geïmplementeerd en getest tot wanneer het klaar is. Dit wil zeggen dat er doorheen het proces sprake moet zijn van waardevermeerderingen (=increments). Het product wordt dus onderverdeeld in componenten, dewelke afzonderlijk gemaakt worden en bij de gebruiker geleverd worden tot wanneer product volledig klaar is en aan alle vereisten voldoet.

Het is dus een model waarbij veel aandacht geschonken wordt aan de feedback die op het prototype gegeven wordt. Zo kan men het aantal herwerkingen en terugkoppelingen in het ontwikkelingsproces beperken doordat fouten vroeg ontdekt worden en dan verbeterd worden.

* bestaat uit onafhankelijke subsystemen

* alle vereisten moeten gekend zijn

* door het afleveren van kleinere units, wordt de feedback en testing verbeterd

*het systeem moet increments hebben, wat wil zeggen dat het waardevermeerderingen moet opleveren

* deze increments moeten nuttig zijn voor de gebruiker

* er is een veel langere ontwikkelingstijd voor nodig

* >< het verbetert echter “ het development risk management” en “ het sequentiële verloop in de subsystemen” niet.

3. Het spiraal model

30

Ook het spiraalmodel kan in verband gebracht worden met prototyping. Het model bestaat uit 4 fasen die achtereenvolgens in een lineair verloop moeten worden uitgevoerd. Na uitvoering van de 4 fasen, kan er besloten worden om deze stappen te herhalen of om het project te beïndigen. Elke keer als er dus een nieuwe component ontwikkeld is, dan kan dit in het systeem geïmplementeerd worden. Het model bestaat dus uit meerdere stappen doorheen de spiraal, waardoor complexiteit en het niveau van detail sterk vergroot is. Ook wordt de gebruiker van het systeem erg hard betrokken.

Deze 4 fasen zijn(+/-)

* Het vastleggen van de vereisten en doelstellingen

*plannen en risicoanalyse, waarbij het alternatief met de minste risico’s

gekozen wordt

* ontwikkeling

* evaluatie

4. RAD model

= Rapid Application Development

31

Het RAD model is een model voor systeemontwikkeling dat bedacht werd als een reactie op de tekortkomingen van het watervalmodel. De duur van de beginfase tot de vervollediging van het systeem is immers veel korter. Deze snellere ontwikkeling kan gerealiseerd worden door het verminderen van de lengte en tijdsduur van de analyse, design en constructiefases door hen te combineren met het gebruik van grafische software tools. Met deze tools kunnen de applicaties/toepassingen dan snel gemaakt worden door gebruik te maken van op voorhand verzamelde componenten.

De componenten zijn specifiek op 1 doel gericht en hebben een zeer korte ontwikkelingstijd van 60-90 dagen.

Er wordt gewerkt met verschillende teams

Nadelen verbonden aan RAD

Het systeem vereist passende componenten De hulpbronnen en kennis zijn voor een groot aantal teams bestemd De prestatie van het systeem kan eronder lijden

Als een gebruiker iets gevraagd heeft, dan moet dat heel snel uit het systeem komen. Als een team immers een groter systeem ontwikkelt, dan zit er altijd tijdsdruk achter. Samenwerking van de componenten kan er echter voor zorgen dat het lang duurt vooraleer je de juist informatie eruit krijgt. Daarom is er goede communicatie nodig opdat de componenten vlug kunnen samenwerken.

De technische risico’s kunnen de project risico’s dramatisch doen stijgen.

Prototyping

32

Zoals op de bovenstaande figuur te zien is, zullen eerst en vooral de vereisten geïdentificeerd worden, waarna er een eenvoudig eerste prototype gemaakt wordt. Dit prototype zal dan door de gebruikers uitgetest worden om na te gaan of de software die zij voorgeschoteld krijgen hen tevreden stelt. Na dit besluit zal er vastgesteld worden of het prototype aangepast moet worden. Als het prototype aanvaard wordt, dan kan men overgaan tot de normale systeemontwikkeling.

Prototype

Een prototype is een gedeeltelijke implementatie van een systeem dat eerst primair gebouwd wordt zodat consumenten, eindgebruikers of de ontwikkelaars van het systeem aandacht krijgen voor eventuele problemen en oplossingen voor deze problemen.

Men gaat dus een systeem steeds opnieuw verbouwen en telkens een stukje afmaken. Als het niet goed is, dan is dit ook eenvoudig aanpasbaar.

Bv. Bij het maken van webpagina’s/ webapplicaties zal men een website in stapjes maken, waarbij men eerst begint met het kader en vervolgens de pagina vervolledigt tot wanneer deze zowel inhoudelijk als uiterlijk helemaal in orde is.

2 soorten prototyping:

1. Trowaway prototyping (= gesloten)

Bij dit soort prototyping wordt het prototype niet gebruikt als basis voor het finale systeem. Onder deze categorie vallen bijvoorbeeld visuele applicaties zoals Visual Basic of Macromedia Director.

2. Evolutionary prototyping

Hier wordt het prototype niet weggegooid, maar dient het als basis voor het finale systeem. ( zie tekening hieronder)

Prototyping is exploratief ( het uitzoeken van de vereisten) en experimenteel (het uitproberen van opties).

33

Het gehele systeem

Enkel kernelementen

Wanneer kan prototyping het best gebruikt worden?

* Bij dynamische visuele displays

* Bij sterke interactie met de gebruikers

* Bij complexe algoritmes of berekeningen

* Bij dubbelzinnige of tegenstrijdige vereisten

5 belangrijke activiteiten/fasen bij projectmanagement

Project managers volgen 5 fasen waar ze antwoorden op de volgende vragen:

1 . Estimation (inschatting) Wat werk is erbij betrokken?

Estimation/inschatting omvat het identificeren van de activiteiten die betrokken zijn bij het project, wat ook wel eens “ Work Breakdown Structure “ genoemd wordt (=WBS)

2. Resource allocation (bronnen allocatie) Wie zal het werk doen?

Hier moeten de gepaste personen toegewezen worden aan de juiste taken.

3 . Schedule (schema/plan) Wanneer zal men het werk doen?

Volgend op ‘de resource allocation’, zal de juiste tijdsduur voor het afmaken van een bepaalde taak bepaald worden rekening houdend met de beschikbaarheid en kwaliteiten van de personen die eraan toegewezen zijn.

* Er zijn ook twee verschillende concepten, namelijk:

- Effort time ( inspanningstijd) = de totale hoeveelheid werk dat er nodig is om een taak te vervolledigen, wat meestal in dagen uitgedrukt wordt.

- Elapsed time ( verstreken tijd) = de tijdsduur dat vereist is om een bepaalde taak te beïndigen. De elapsed time is afhankelijk van het aantal deelnemers en hun kwaliteiten.

34

* Ook gaat men bij het plannen milestones(= mijlpalen) herkennen. Dit zijn controlepunten in het project die het einde van een belangrijke fase aanduiden (BV. het bepalen van de vereisten, het afsluiten van het project,…)

Milestones hebben meestal duidelijk gedefinieerde ‘deliveralbles’ (= uitkomst), welke de resultaten zijn van een fase binnen het project (BV. specificaties of een softwareversie).

4. Budgetting (budgetteren) Wat is de kost van het project?

In deze fase worden de kosten voor personeel en hardware- en softwarebenodigdheden bepaald. Dit gaat men bepalen door een allocatie van taken en hulpbronnen.

5. Monitoring and control Hoe verloopt het project?

Monitoring = controleren of het project volgens plan verloopt.

Controle= corrigerende maatregelen nemen als het project afwijkt van het plan.

Meer bepaald zal de project manager ‘mijlpalen willen bereiken en zal hij daarom de ‘ deliverables’ controleren om na te gaan of deze aan de vereisten voldoen.

Instrumenten om het project management proces te ondersteunen

Veel managers gebruiken software-instrumenten om te gebruiken gedurende de 5 fases van projectmanagement.

-Vaak worden “project views” gebruikt, welke methodes zijn om het projecttaken, hulpbronnen en plannen te visualiseren. Een voorbeeld hiervan is het Gannt schema. Dit is een horizontaal staafdiagram of tijdlijn waarop projectactiviteiten en mijlpalen aan de linkerkant opgesomd worden. De data worden vervolgens bovenaan het schema weergegeven, terwijl de tijdsduur van de activiteiten voorgesteld wordt door de horizontale staafjes. ( zie figuur hieronder)

35

- Om de afhankelijkheid tussen taken te herkennen, wordt er een “netwerk diagram” opgesteld. Dit diagram toont duidelijk de keten van activiteiten en de volgorde waarin ze moeten gebeuren. Bij deze activiteiten, worden eigenschappen opgesomd als startdatum, einddatum, effort time en hulpbronnen. Een netwerk diagram is heel handig aangezien het duidelijk het “kritische pad” van een project weergeeft. ( zie figuur hieronder)

Methodes om het project management proces te ondersteunen

36

Project management methodes zijn richtlijnen die een standaard benadering bepalen voor de 5 belangrijkste elementen van het project management proces.

Eigenschappen van veel soorten methodes ( maar specifiek deze van de Prince2 methode)

-Het project wordt onderverdeeld in beheersbare fases die toelaten dat er regelmatige controle is op de vooruitgang

-Verantwoordelijkheden en rollen binnen het project worden duidelijk gedefinieerd

-Projectplanning is “product-based”. Dit wil zeggen dat een project ook echt resultaten aflevert, en niet enkel plannende activiteiten uitvoert.

-Een project wordt uitgevoerd ter verbetering van het bedrijf. Er wordt daarom een “business case” opgemaakt waarin de rechtvaardiging en toewijding om het project uit te voeren, uiteengezet worden.

-De methode zorgt ervoor dat er betere communicatie ontstaat tussen het project team en de hele organisatie.

Er zijn verschillende methodes:

Specifieke project management methoden

De PRINCE2 methode

PRINCE2 is een proces gebaseerde methode voor project management. Elk PRINCE2 proces zal input en output definiëren, maar ook de activiteiten die uitgevoerd moeten worden om de doelstellingen van het proces te bereiken. De eigenschappen van de PRINCE2 methode zijn eigenlijk identiek aan deze die hierboven opgesomd werden.

PRINCE2 gebruikt ook het concept van “Project tolerantie”. Project toleranties zijn eigenlijk controlemechanismen die gebruikt worden om bepaalde zaken onder de aandacht van het management te brengen wanneer het werkelijke project afwijkt van wat er gepland was.

Euromethode

37

Britisch Standard 6079

The dynamic Systems Development Method ( DSDM)

DSDM is special ontwikkeld om te werken met prototypes.

COBIT IT governance framework

Methodes met aandacht voor de analyse van de behoeften van de gebruiker en het bedrijf ivm systemen

= “Systeemanalyse en design methodes”

Soft Systems Methodology (SSM)

Deze methode identificeert de vereisten van de gebruiker en het bedrijf voor een systeem, veranderingen ervan voor het bedrijf, en de benodigde processen.

Systems Analysis and Design Method ( SSADM)

Deze methode definieert analyse- en designmethodes voor een grootschalig software ontwikkelingsproject. SSADM wordt voornamelijk gebruikt in de UK en meer specifiek in publieke- en overheidsorganisaties.

De belangrijkste activiteiten doorheen de 5 fases in System Development/Systeemontwikkeling

Afhankelijk van de methodologie die je gebruikt, ga je bepaalde fases apart afhandelen, terugkoppelingen doen, enz…

1. System initiation phase (systeem initiatiefase)

2. Systems analysis phase (systeem analysefase)

38

3. Systems design phase (systeem ontwerpfase)

4. Systems development phase(systeem ontwikkelingsfase)

5. Systems maintenance phase (systeem onderhoudfase)

1. De initiatiefase

De initiatiefase is de startfase in een informatiesysteem ontwikkelingsproject. In deze fase gaat men controleren of het project uitvoerbaar (feasible) is en stelt men een projectplan op.

Tijdens de initiatiefase zoekt men naar antwoorden op de volgende vragen om zodoende te weten wat men wil bereiken met het systeem:

- WAT gaat er gebeuren?

- WAAROM gebeurt dit?

- WIE zal het doen?

- HOE wordt dit dan bereikt?

- Wanneer gaat het gebeuren?

Belangrijkste activiteiten uit de initiatiefase:

A. Feasibility study (= uitvoerbaarheidonderzoek)

Het uitvoerbaarheidonderzoek evalueert de nood aan en de impact van het systeem en de manier waarom het gemaakt zal worden. Het resulteert dus eigenlijk in een uitvoerbaarheidrapport (feasibility rapport) dat de levensvatbaarheid/ slaagkansen van het systeem inschat.

39

B. Project plan

Het projectplan bepaalt de activiteiten voor het project, de menselijke en technische hulpbronnen, schema en kader, risicomanagement plan, budget,…

Het project initiatie document

Dit document beschrijft de doelstellingen, waaronder de bedrijfsdoelstellingen

(BV. stijging marktaandeel met 25%) en de projectdoelstellingen. De projectdoelstellingen zijn echter veel specifieker, aangezien zij exact bepalen wat het project moet afleveren (BV. de invoer van een e-commerce handelsysteem).

Ook bepaalt het project initiatie document de grensafbakening (= wat is inbegrepen en wat niet?). Voorwaarden die vermeld worden in dit document zijn hard- en softwareplatforms ( ga je het systeem op 1 platform laten draaien of op meerdere?), tijd en hulpbronnen ( zoals Bv. bijkomende programmeurs) .

Typische problemen in de initiatiefase:

*Er wordt onvoldoende tijd aan besteed. Dit komt doordat teamleden vaak zo snel mogelijk verdoen met hun werk en dus verblind zijn door enthousiasme voor het project zelf.

*Vaak zijn doelstellingen en plannen voor het project eerder onrealistisch, waardoor het budget overtroffen wordt. Als men dan onvoldoende benodigdheden bij elkaar kan krijgen, dan betekent dit dat de activiteiten, het budget en ook de tijdsduur onderschat werden.

40

*Het kan ook zijn dan organisatorische, operationele en technische risico’s niet herkend worden, wat voor problemen zorgt in verdere fases van het project.

Bv: Bij een initiële fase zullen de gebruikers het nieuwe systeem gebruiken, maar vaak zijn ze hier niet op voorbereid. Men moet hier dus een oplossing voor vinden.

2. De analysefase

De analysefase is de fase waarin, van zowel het bedrijf als van de gebruikers, de vereisten voor het informatiesysteem vastgesteld worden. Er wordt gebruik gemaakt van “fact-finding techniques” om erachter te komen wat de wensen van de gebruiker zijn. Deze worden samengevat in een reeks van documentatie en diagram methodes.

System analysis/ systeemanalyse

= De vaststelling van informatiesysteemvereisten.

Definiëren van ‘ wat het systeem moet kunnen’

De output bestaat uit specificaties van de wensen en vereisten

Belangrijkste activiteiten uit de analysefase/ systeemanalyse

Dit zijn allemaal methoden om informatie te verzamelen over de vereisten in verband met het nieuwe systeem in een bedrijf.

A. Focusgroep (= kerngebruikers)

Focusgroepen zijn zeer nuttig tijdens de initiële fase van het project om zo reeds grote belangrijke aspecten voor het project te bepalen.

B. Documentatie

Men zoekt documentatie uit bestaande informatiesystemen om zo te weten te komen wat de vereisten voorheen waren. Dit dient dan als basis voor het nieuwe systeem, aangezien de vereisten vaak sterk overeenkomen.

Bv: een handleiding

41

C. Enquêtes

Men stuurt vragenlijsten naar potentiële gebruikers en gebruikers van het oude systeem. Zo komt men te weten wat de wensen zijn van de gebruikers. Deze vragenlijsten kan men ook best voorleggen alvorens het afnemen van een interview.

D. Observatie

Hier wordt geobserveerd hoe de huidige gebruikers omgaan met het bestaande systeem.

E. Interviews

Gestructureerd of open ?

F. Prototyping

Doordat men op papier of over de computer prototypes toont, kan men vanzelf de vereisten verzamelen.

G. Het vaststellen van de specificatie van de vereisten

- Vereisten van het bedrijf en de gebruikers

- Welke werkactiviteiten zal het systeem ondersteunen?

- Welke informatie zal er beschikbaar zijn?

- Welke informatie zal het systeem opnemen?

- …

Typische problemen in de analysefase

Vaak voert men geen uitvoerige analyse uit. Daarom is het belangrijk om alle bovenstaande technieken toe te passen bij zo veel mogelijk mensen.

3. Systeem designfase

42

De designfase bepaalt hoe het finale systeem tewerk zal gaan. De output hiervan is dan ook de specificatie van het design. Men gaat hier dus eigenlijk de modellen die men ontworpen had tijdens de analysefase, echt specifiek ontwikkelen.

Design is opgesplitst in twee fases, namelijk:

* Systems design ( systeemdesign)

Deze fase bepaalt de algemene structuur van het systeem en zijn outputs en inputs.

* Module design

Deze fase bepaalt hoe elk subsysteem zal werken en hoe het dan ook verder onderverdeeld wordt in kleinere subsystemen.

Belangrijkste activiteiten uit de designfase/ systems design

Software architectuur : definieert hoe verschillende modules zullen werken onder de vorm van programmeertaal. Systeemmodules of objecten zullen verder afgebroken worden tot individuele programmafuncties of methodes. Men gaat hier dus aangeven hoe het systeem werkt, welke gebruikers er zijn, hoe de schermen er zullen uitzien, enz…

Hardware architectuur: definieert de nood aan verschillende hardwareonderdelen of infrastructuur.

Informatiearchitectuur: bepaalt de inputs en outputs van informatie in het systeem en bepaalt ook de beste methode om informatie te beheren in het systeem. Een onderdeel van de informatiearchitectuur is dan ook het “database design”.

Security design: definieert hoe informatie beschermd wordt, wetende dat verschillende groepen van gebruikers toegang zullen hebben tot de date/ informatie.

User interface design: definieert de vele schermen die gebruikers zullen tegenkomen in het systeem. Hieronder vallen de menuopties, invoegtabellen, enz.

Typische problemen in de designfase:

* Hoewel de designfase gebaseerd is op de vereistenspecificatie, is er toch veel overlapping tussen de analyse- en designfase.

* Designers kunnen vinden dat de vereisten/wensen niet genoeg gedetailleerd aangeven wat er nodig is voor het systeem. Vaak maken ze dan ook bijkomende

43

voorstellen tot verbetering. In dit geval, is het zeker en vast nodig om de gebruikers van het systeem te raadplegen.

* Tijdens deze fase kunnen er grote vertragingen optreden indien de communicatie tussen de designers, de analisten en de gebruikers niet vlot verloopt. Daarom zou men aan prototyping moeten doen, opdat de gebruikers steeds betrokken blijven.

*Vaak wordt er, zoals bij vele fases, onvoldoende tijd gestoken in de designfase. Hierdoor kan het zijn dat men opnieuw aan deze fase moet werken in een later stadium.

4. Systems development phase/ontwikkelingsfase

Tijdens de ontwikkelingsfase wordt het fysieke systeem gecreëerd door de technische ploeg. “Systems development phase” is de creatie van het systeem door programmering, databank management en configuratie.

Belangrijkste activiteiten uit systems development/systeemontwikkeling

1. Het programmeren van individuele systeemmodules en het bijstellen van fouten of “bugs” in het systeem.

2. Het creëren van databankstructuren en datamanipulatie functies zoals databank triggers en opgeslagen procedures.

3. Het creëren van de gebruikersinterface om zo toegang te krijgen tot de webbrowsers.

4. Het testen van de databank, programma’s en interface.5. Het schrijven van systeemdocumentatie voor de gebruikers en toekomstige

ontwikkelaars.

Typische problemen in ontwikkelingsfase

* Het grootse probleem tijdens de fase is het feit dat er tijdens de ontwikkeling vaak bugs of fouten in het systeem optreden. Als men zo’n groot systeem wil ontwikkelen, dan vraagt dit immers 10, 100 of zelfs 1 miljoen regels met codes. Zelfs de meest ervaren programmeurs maken gemiddeld rond de 10 fouten per 1000 regels. Elke regel biedt dus de mogelijkheid tot een fout, wat het systeem helemaal kan vernielen.

44

* Een ander groot probleem is de regelmatige wijziging van de specificatie.

5. Systems implementation phase / implementatiefase

System implementation/ systeem implementatie houdt het uitvoeren of de introductie van het nieuwe informatiesysteem in het bedrijf in. Men gaat hierbij eerst testversies van het systeem verdelen, waarna men de testresultaten verzamelt. Als deze resultaten positief zijn, dan wordt het systeem ter beschikking gesteld van gebruikers binnen het bedrijf. Men gaat dus de “changeover” van het oude naar het nieuwe systeem realiseren.

De changeover/migratie is dus de methode waarbij men gebruikers en data migreert van het oude naar het nieuwe systeem.

Belangrijkste activiteiten uit de Systeem implementatie

1. Changeover

Leer kader !

In realiteit is je nieuwe systeem zo anders dat je nog qua functionaliteit, noch qua database het nieuwe systeem naar het oude kan gebruiken !

45

2. Data migration/ datamigratie

Dit is de overdracht van data van oude systemen naar nieuwe systemen. Men noemt dit ook wel eens het bevolken van de database(= populating the database/ data conversion).

3. Testing

Het systeem wordt steeds getest bij de eindgebruikers voordat het definitief gebruikt wordt.

Typische problemen in de implementatiefase (afhankelijk van de keuze van de changeover!)

* Tijdens de changeover fase gebeurt het regelmatig dat het systeem faalt (zie casestudy 7.2 pagina 375).

* De faling van het systeem tijdens deze fase kan veroorzaakt zijn door onverwachte problemen die niet getest waren in de testomgeving. Wanneer het systeem dan live gaat, dan treden deze problemen uiteraard wel op. Bijvoorbeeld: De druk op een live systeem kan hoger zijn dan in de testomgeving.

* Een ander probleem is dat men niet graag de live data vertraagt of uitstelt, ondanks het feit dat het systeem niet volledig getest is.

6. Systems maintenance phase/Systeem onderhoudsfase

“Systems maintenance” of “systeemonderhoud” houdt in dat men het systeem beheert vanaf het ogenblik dat het live gebruikt wordt. Men zal dus alle problemen in het systeem moeten oplossen. Ook zullen sommige bedrijven terugblikken op het project om van hun ervaringen te leren. Dit doet men via een “project closedown review” (= projectafsluitingsbespreking).

46

De belangrijkste activiteiten uit de onderhoudsfase

Wanneer er ernstige problemen en fouten gevonden worden, dan moeten deze onmiddellijk gemeld, besproken en opgelost worden. Men brengt dus een ‘patch’ release uit aan het systeem.

Een formele bespreking kan ook optreden op het einde van de projecten. Dit noemt men een post-implementation review. Hierbij wordt het succes van het systeemontwikkelingsproject ingeschat en trekt men lessen voor toekomstige projecten.

Typische problemen in de onderhoudsfase

* Er treden meestel problemen op in de onderhoudsfase omdat de onderhoud niet echt deel uitmaakt van het gehele project. Daarom zullen processen voor berichtgeving, bespreking, aanpassing en verwittiging van problemen niet echt op hun plaats zijn.

* Een “project closedown review” is vaak weggelaten in organisaties die geen project kwaliteitmanagementsysteem, vermits het eigenlijk veel gemakkelijker is om te beginnen aan een volgend project en problemen met een project in de doofpot te steken.

Specifieke kwesties/risico’s van internetgebaseerde projecten

Initiatie: Opleiding waarbij men het nut van internet en het belang van updaten uitlegt. Er wordt ook uitgelegd hoe belangrijk het is om de return on investment juist te berekenen bij informatiegebaseerde projecten.

Analyse en design: Dit zijn speciale methodes om de informatievereisten in kaart te brengen. (hoofdstuk 9)

Ontwikkeling: De designfase is relatief gezien nogal gelimiteerd vergeleken met de meest besproken applicaties. Dit is zo omdat een contentmanagementsysteem, zoals CRM applicaties of e-commerce, gebruikt zal worden om structuren te creëren voor “data storage of gegevensopslag’. De ontwikkeling van het internetgebaseerde gebruikersinterface echter, vereisten specifieke deskundigheid, dewelke verschillen van niet-internetgebaseerde applicaties. (hoofdstuk 9)

47

Implementatie: Er zal veel werk nodig zijn om het systeem te vullen met informatie. Aangezien veel van deze informatie al beschikbaar zal zijn, zullen integratiemethodes met andere systemen nodig zijn ( BV. exporteren van de informatie van andere systemen en dan importeren van deze informatie).

Onderhoud: De onderhoudsfase is vooral belangrijk in dit soort projecten, aangezien de inhoud steeds up-to-date moet gehouden worden door middel van onder andere update mechanismen. Het gebruik van verschillende types informatie in internetgebaseerde systemen kan onmiddellijk nagegaan en geëvalueerd worden om zo het belang van de informatie te bepalen. Daarom moeten controles aanwezig zijn opdat de kwaliteit van informatie behouden blijft.

Methodology customization

Probeer alles zo eenvoudig mogelijk te doen !

Men moet steeds de structuur van de oplossing doen overeenstemmen met de structuur van het probleem ( Don’t use a hammer to drive a screw !)

‘ Customization’ is gebaseerd op de grootte en complexiteit van het systeem, het ontwikkelingsrisico, de beschikbaarheid van personeel en hulpbronnen, de gebruikerservaring, de vereiste controles en systeemrisico’:

o Customize a single approacho Customize a multiple approach

De mensen die betrokken zijn bij het project:

ProjectmanagerSysteemanalysten en systeemdesignersDatabankanalysten en databankdesignersGebruikersProgrammeursDatabase Administrators (DBAs)/ databankbeheerderNetwerkexpertsAndere technische experts

Projectmanager:- Stelt zijn projectteam samen- Maakt gedetailleerde projectplannen op- Houdt toezicht op de mensen en het plan- Werkt samen met andere managers- Wordt uiteindelijk verantwoordelijk gehouden voor het succes van het

systeemontwikkelingsproject.

Systeemanalysten en systeemdesigners- Leggen de nadruk op de wensen en behoeften van het bedrijf- Vormen een brug tussen het bedrijf en technologie

48

- Werken met systeemfuncties en data- Analyst: “ What should be done?”- Designer: “ How should it be done?” ( meer nadruk op technologie)

Databankanalysten en databankdesigners- Leggen ook de nadruk op de wensen en behoeften van het bedrijf- Vormen een brug tussen het bedrijf en technologie- Leggen hun primaire focus op datavereisten- Analyst: “ What date is needed?” - Designer: “ How should it be stored?”

Gebruikers- Zijn de uiteindelijke gebruikers van het nieuwe systeem- Bezorgen informatie over hun vereisten en de behoeften van het bedrijf- Herzien en beoordelen documentatie- Testen & accepteren het nieuwe systeem- Trainen andere gebruikers- Kunnen mogelijk de reeds bestaande of actuele gebruikers zijn

Programmeurs- Ontwerpen programma’s (= detailed design)- Schrijven programma’s- Testen van programma’s- Schrijven SQL ( een computertaal in databanken) voor databanktoegang

Database Administrators/databankbeheerders- Eindverantwoordelijken voor huidige en toekomstige databanken- Voorzien data en ‘modeling expertise’- Voorzien DMBS(databasemanagementsysteem) expertise- Beheren en regelen databanken

Andere technische experts- Zij brengen expertise op verschillende gebieden, namelijk networking,

besturingssysteem, hardware, taalontwikkeling, ontwikkeling van methodes en tools.

49

Hoofdstuk 8: Change management

Introductie

Het verbeteren van organisatorische prestaties m.b.t informatiemanagement gaat vaak gepaard met nieuwe benaderingen t.o.v arbeid, en zo ontstaat er een nood aan het ‘managen’ van deze verandering.

Change management

= Benaderingen die bedoeld zijn om veranderingen in de organisatorische processen en structuren te beheren en hun impact op het organisatorisch leidinggevend personeel en de cultuur.

Doordat managers de reacties van de werknemers op de nieuwe manier van werken vaak verwaarlozen, is het falingspercentage hoog voor projecten bij informatiesystemen. De nood aan het managen van veranderingen is niet enkel van toepassingen op de veranderingen in het informatiesystemen, maar is even belangrijk voor alle initiatieven m.b.t bedrijfsinformatiemanagement. Of het nu gaat om een introductie van een nieuw ‘enterprise resource planning system’, een internetfaciliteit voor knowledge management, het begeleiden van een informatie-audit, of om een implementatie van een bestuur om de data quality te verbeteren.

Bij een introductie van nieuwe informatiesystemen moeten de gebruikers leren werken met de nieuwe systemen, maar kan ook gepaard gaan met een nieuwe methode van werken. Het kan dan gaan om een ‘Business transformation

Business Transformation

= belangrijke veranderingen in de organisatorische processen die ingevoerd zijn om de organisatorische prestaties te verbeteren.

Bijvoorbeeld:Werknemers die voor vele jaren altijd ‘face-to-face-contacten’ hadden met de klanten of leveranciers, worden nu gevraagd om technologie te gebruiken, die het humane contact uitsluit.

50

Different types of change

2 soorten veranderingen:

1) Incremental change = continuous change (graduele verandering)= relatief kleine aanpassingen die noodzakelijk zijn voor een organisatie in overeenstemming met de bedrijfsomgeving. Vb. Toen de gsm voor het eerst op de markt werd gebracht, was dit oorspronkelijk enkel voor mensen uit de bedrijfswereld. Nadien zijn ook enkele particulieren het toestel beginnen te gebruiken, en zo geleidelijk ook de jongeren,… Bedrijven moeten reageren op deze veranderingen.

2) Discontinuous change = transformational change (grote verandering)= een verandering die een belangrijke transformatie met zich mee brengt in een onderneming, woordoor de concurrentiële positie wijzigt. Vb. airline industry: de snelle reductie van passagiersvluchten door de aanslagen van 9/11.

Hoe hebben deze 2 soorten veranderingen effect op de organisatie en op de personen verbonden aan die onderneming?

Organizational change= Er kunnen zowel graduele als grote veranderingen plaatsvinden. Zo’n veranderingen vinden plaats wanneer management teams inspelen op de veranderingen in de omgeving door hun strategieën aan te passen samen met het karakter van hun organisaties.

Types van organizational change (McKinsey 7Ss model, chapter 6 p.295):

Hard ‘Ss’ Soft ‘Ss’

1. Strategy : de allocatie van de middelen om de doelstellingen te bereiken

2. Structure : structurele veranderingen zijn vanzelfsprekend wanneer er nieuwe strategieën toegepast worden of in geval van fusies.

3. Systems : veranderingen in operationele procedures en in bedrijfsprocessen zullen eveneens een impact hebben op de informatiesystemen.

1. Skills : zijn de juiste vaardigheden aanwezig? Welke training is er vereist?

2. Superordinate goals : de informatiesystemen moeten de hogere doelstellingen steunen die in de mission statement omvat zijn.

3. Staff : zijn de geschikte arbeidskrachten beschikbaar bij een introductie van een nieuw informatiesysteem?

4. Style : de bedrijfscultuur heeft niet echt een directe invloed op de informatiesystemen

51

↓In de context van informatiesystemen kunnen aanpassingen vereist zijn als onderdeel van de implementatie van de nieuwe aanpak. Voor nieuwe systemen met een incremental change, zijn de skills, systems en staff van toepassing.Voor systemen die een discontinuous change ondergaan kunnen al de 7 Ss’n van toepassing zijn.

Indelen van de verschillende types van organizational change.

Het concept van graduele en indiscontinuous change wordt gecombineerd met anticeptory change of met reactive change.

Anticeptory change (anticiperende verandering)= wanneer een organisatie proactieve veranderingen doorvoert om zijn efficiëntie te verbeteren of om een competitief voordeel de behalen. Er is niet onmiddellijk nood aan reactie.

Reactive change (reactieve verandering)= Een directe reactie op een verandering in de externe omgeving van de organisatie.

52

1) Tuning: ‘doing things better’dit is een graduele verandering waarbij er geen onmiddelijke nood aan verandering is. Nieuwe procedures of een nieuw bestuur kan gebruikt worden om de efficiëntie van het proces te verbeteren. Vb. tijd minimaliseren of kosten verlagen.

2) Adapting: ‘doing things better’dit is een graduele verandering als antwoord op een externe dreiging of kans. Dat antwoord is nodig, maar het zorgt niet voor een beduidende verandering in de competitiviteit. Vb. een concurrent lanceert een nieuw product, of er is een fusie tussen 2 rivalen.

3) Re-orientation: ‘doing things differently’er is een beduidende transformatie voor de organisatie, wat betekent dat het om een discontinuous change gaat. Er is geen onmiddellijke nood aan verandering, maar in afwachting van verandering. Vb. Toen IBM als eerste de ‘e-business’ introduceerde, was dit een re-orientation voor de manier waarop de service geleverd werd. Dit was een aanmoediging voor een wijdere verandering in de manier van werken.

4) Re-creation : ‘doing things differently’het senior management team van een organisatie beslist dat er een fundamentele verandering nodig is in de manier werken om te kunnen concurreren. Vb. airline industrie: vliegmaatschappijen moeten hun programma aanpassen aan de low-cost carrier door bijvoorbeeld een betere kwaliteit van de service te bieden, of door zelf ‘voordeligere’ low-cost services te bieden.

Different scales of managing change

Informatiemanagementsystemen zijn meestal niet direct gedreven door veranderingen in de markt. Ze zijn eerder bedoeld om prestaties te verbeteren door de efficiëntie te verhogen als onderdeel van voortdurende verbetering. Het systeem zal de werknemers bereiken en deze zullen aangemoedigd moeten worden om het systeem toe te passen.

Business process management (BPM)

= een benadering die ondersteund is door software tools die bedoeld zijn om de efficiëntie van het proces te verhogen door de informatiestroom tussen mensen te verbeteren als ze aan het werk zijn. Het gaat hier om een incremental change.

Business Process Re-engineering (BPR)

= het identificeren van radicaal nieuwe manieren om business operations te voltrekken,

53

meestal in staat door nieuwe IT bekwaamheid.

‘Hammer en Champy’ definiëren BPR als: het fundamenteel herbedenken en radicaal herontwerpen van business processen om dramatische verbeteringen te bereiken in kritische, hedendaagse metingen van performance, zoals kosten, kwaliteit, service en snelheid.

Fundamenteel herbedenken : re-engineering verwijst meestal naar veranderen van betekenisvolle bedrijfsprocessen zoals klantenservice, manufacturing,…

Radicaal herontwerpen: re-engineering houdt een complete herbedenking in van de manier waarop bedrijfsprocessen werken.

Dramatische verbeteringen: de intentie van BPR is om verbeteringen te bereiken die gemeten worden in %. Hier zijn alleen single-figure verbeteringen mogelijk.

kritische, hedendaagse metingen van performance: meten hoe goed de processen werken in termen van de 4 belangrijke maatstaven (kosten, kwaliteit, service, snelheid).

Willock en Smith (1995) karakteriseren de typische veranderingen die opkomen in een organisatie bij een procesinnovatie als:

1. Werkeenheden veranderen van functionele departementen in process teams. 2. Jobs veranderen van simpele taken in multidimensionaal werk3. Rollen van de mensen veranderen van gecontroleerd in ‘in staat stellen’ (empowered)4. De focus van de prestatie verandert van activiteiten in resultaten5. Waarden veranderen van beschermend naar productief (protective naar productive)

Models of change

Als mensen veranderingen ondergaan, ervaren zij altijd een variëteit van emoties. Dit zijn persoonlijke overgangsfasen of reacties op veranderingen (zie tekening)Een persoon zou elke fase ondergaan tijdens de verandering. Door de veranderingen te managen, zou het mogelijk zijn om de grootte van de gevoelens te reduceren, of om delen van het proces te versnellen.

De hoofdelementen van die overgangsperiode zijn:

1. Het besef/shock (Shock). Meestal snel gevolgd door angst of zelfs paniek. De grootte van de shock hangt af van de wenselijkheid van de overgang en hoe goed de persoon daarop voorbereid is.

2. Ontkenning (Denial). Het gaat om het ontkennen of het onderwaarderen van negatieve consequenties, en vaak het richten van de aandacht op andere punten.

54

3. Depressie (Depression). Dit gebeurt als de persoon zich realiseert dat de verandering is onomkeerbaar. Het ontevreden gevoel kan leiden tot woede en bestrijding van de nood aan verandering.

4. Laten gaan (Letting go). Op dit punt ervaart de persoon de noodzaak om verder te gaan en start met zich niet meer te associëren met de vorige situatie.

5. Testen (Testing). De persoon begint te experimenteren met de nieuwe situatie. De acceptatie kan toenemen, maar woede kan nog altijd boven komen als er problemen ondervonden worden.

6. Consolidatie (consolidation). De persoon bouwt op de positieve aspecten van de verandering en minimaliseert de negatieve.

7. Acceptatie (Acceptance). Acceptatie vindt plaats als de nieuwe situatie als ‘normaal’ aanschouwd wordt.

Maar wanneer personen met veranderingen geconfronteerd worden, kunnen ze ook verzet tonen (resistance to change). Dit houdt in dat het personeel actief of passief hun bezwaren tegen de nieuwe manier van werken toont.

Ook indirecte sabotage is mogelijk (systems avoidance). Dat is wanneer de eindgebruiker van een systeem verzet toont door het systeem niet meer te gebruiken of in mindere mate.

Vb. een B2B sales-representative of een account manager worden geconfronteerd met een ‘sales force automation system, waarin ze alle meetings en telefooncontacten met mogelijke klanten moeten registreren. Ze kunnen beslissen om sit systeem niet te gebruiken omdat ze bijvoorbeeld heel traditioneel zijn en van mening zijn dat verkopen om mensen gaat en niet om technologie. Of ze kunnen vinden dat ze daar geen tijd voor hebben. In plaats van het systeem te gebruiken kunnen ze een manueel systeem met papier gebruiken, of een persoonlijk systeem dat ze bij andere bedrijven gebruikten.

55

Het is belangrijk voor de managers om de reden van verzet te kennen.

Er zijn enkele mogelijke manieren om verzet te tonen tegen veranderingen :

1. Agression: waar er fysieke sabotage kan zijn aan het systeem, opzettelijke invoer van foute date of misbruik van de systems staff

2. Projection : waar het systeem verkeerd beschuldigd is van moeilijkheden die boven komen tijdens het gebruik van het systeem.

3. Avoidance :Het achteruitsteken of het vermeiden van interactie met het systeem, het niet invoeren van data, berichten en enquiries negeren, of het gebruiken van manuele substitutie voor het systeem.

4. Criticism: Verontrustingen omtrent het systeem worden luidop uitgesproken, ook al zijn deze misschien niet correct.

Mastering business Analysis

Er zijn verschillende mensen en rollen betrokken bij ‘Systems Development’:

1. De Project Manager De Project Manager is een belangrijk persoon omdat deze het hele project moet leiden. Hij/zij moet:

1) een projectteam samenstellen2) gedetailleerde plannen maken van het project3) toezicht houden op de mensen die meewerken en dat alles verloopt volgens

het opgestelde plan4) samenwerken met het management van de andere delen van het bedrijf5) uiteindelijk is het de project manager die verantwoordelijk is voor het succes

van het ‘system development project’

2. De Analisten en de Ontwerpers van het systeem (Analysts & Designers)Zij moeten:

1) zich focussen op de bedrijfsnoden en daar rekening mee houden bij het opstellen van het systeem

2) deze personen vormen een brug tussen de business en de technologie in een bedrijf

3) ze zijn verantwoordelijk voor de system functions en data4) analist: ‘what should be done?’ (wat zou er gedaan moeten zijn?)5) designer: ‘How should it be done?’ (Hoe zou het moeten gedaan worden?).

De designer heeft dan ook een grotere focus op de technologische kant.

56

3. De Analisten en de Ontwerpers van de databaseZij moeten:

1) zich focussen op de bedrijfsnoden en daar rekening mee houden bij het opstellen van de database

2) deze personen vormen een brug tussen de business en de technologie in een bedrijf.

3) Ze moeten zich vooral concentreren op de data requirements4) Analist: ‘what data is needed?’ (Welke data is er nodig?)5) Designer: ‘How should it be stored?’ (Hoe moet alle data opgeslagen

worden?)

4. De gebruikers (users)1) het gaat hier om de ultieme gebruikers van het systeem2) zij bepalen wat er vereist wordt, de bedrijfsnoden3) de users beoordelen de documentatie4) Zij moeten het nieuwe systeem testen en accepteren5) Ze moeten eventueel andere gebruikers trainen en inwerken in het systeem6) Het is mogelijk dat deze gebruikers de ‘actual users’ vertegenwoordigen

5. De Programmeurs 1) Zij moeten het programma ontwerpen (een gedetailleerd ontwerp)2) Vervolgens moeten ze het programma dat ze ontworpen “schrijven”3) Daarna wordt het geschreven programma getest4) Als laatste stap schrijft hij/zij een SQL voor de Access database

6. De Database Administrator 1) De database administrator heeft de uiteindelijke verantwoordelijkheid voor de

databases; zowel de dag van vandaag als in de toekomst.2) Het verschaffen van data en het modelling van vakkennis3) Voorzien van vakkennis omtrent DBMS (the DataBase Management System)4) Toezicht houden over en eventueel bijstellen van de database

7. Andere technische experts De technische experts moeten hun vakkennis inbrengen in sommige specifieke onderdelen.Zoals in:- Netwerken- Operating systems- Hardware

57

- De ontwikkeling van talen- Ontwikkeling in methodologie en tools

Bij projecten kunnen er zich ook talrijke problemen voordoen:

1. Het project kan te grootschalig zijn (too large)2. Het project kan ook te moeilijk zijn (too complex)3. Het project kan ook te veel tijd in beslag nemen zodat het moeilijk uitvoerbaar wordt

(too long)4. Projecten betrekken bijna altijd een beduidende IT component5. Er bestaat een constante druk om te leveren: sneller, beter en goedkoper6. Projecten puzzelen constant met risico’s:

omdat ze soms werken met technologie die nog niet bewezen is omdat ze soms moeten werken met uitbestede, mondiale teams omdat de projecten geïmplementeerd moeten worden in alle delen van de

onderneming

In het verleden hebben projecten een somber verslag:

58

Vandaag is het verslag nog steeds zorgwekkend:

Projecten in de 21 ste eeuw

Professor Stephen W. Hawking, PhD:

“I think the 21st century will be the century of complexity”

Bijna alle organisaties van gelijk welke grootte investeren in een large-scale-transformatie van een bepaald type.

Hedendaagse projecten voegen waarde toe aan de organisatie door:

- Ideeën die voor een doorbraak zorgen (breakthrough ideas)- Bedrijfsprocessen te optimaliseren- Informatietechnologie te gebruiken als een competitief voordeel

Vandaag de dag is er geen enkel systeem meer waarvoor je een eenvoudige database kan gebruiken. Hoe komt het dat er zoveel complexiteit heerst omtrent projecten?

↓

1. Het initiatief nemen om aan een project te starten wordt vaak voortgebracht door:- fusies of overnames- de ontwikkeling van nieuwe strategieën- door toenemende wereldwijde concurrentie

59

- het verschijnen van nieuwe technologieën- de noodzaak om verspilling uit het bedrijf te verdrijven

2. Meestal gaan veranderingen in een organisatie gepaard met:- een herstructurering in de organisatie- nieuwe partnerships- een transformatie van de bedrijfscultuur- een verandering naar een efficiënter computer systeem (right-sizing) of een vereenvoudiging van de systemen (downsizing)

3. Andere bedrijven voeren nieuwe businesslijnen in, of passen een nieuwe manier van zaken doen toe. Vb. e-business

De nieuwe Projectleiders (PM = Project Managers) zijn ‘Strategy executors’.

In het verleden waren Project Managers eerst uitvoerders van oplossingen.- Een bekrompen oriëntatie zorgde ervoor dat de focus lag op de

technische uitvoering- De vaardigheden waren beperkt en dat leidde de focus op het budget, op

schema’s, en op de kenmerken van de machines (specs)

De rol van Project Managers heeft een enorme transformatie ondergaan door de nieuwe business realiteit:

- Een doeltreffend management wordt gelijkwaardig aan een doeltreffend businness management.

- Vaardigheden worden verruimd. Ze moeten alle aspecten van het business management omvatten.

De rol van de Business Analyst wordt geprofessionalliseerd

Het fenomeen ‘leadership teams’ doet zijn intrede bij projecten in het bedrijfsleven.

International Institute of Business Analysis (IIBA)

= de onafhankelijke professionele non-profit associatie, die het groeiende veld van Business Analysis dient. Of je nu verantwoordelijk bent voor requirements management, requirements analysis, voor de systems analysis, project management of consulting, IIBA kan een hulp zijn om je taak beter te vervullen.

IIBA definieert Business Analysis als:

= een set van taken en technieken die gebruikt worden als een verbinding onder de stakeholders om de structuur, het beleid en operations van een organisatie te begrijpen en om oplossingen aan te raden die het bedrijf in staat stellen om zijn doelen te bereiken.

60

Onder Business Analysis verstaan we:

- Het identificeren van bedrijfsproblemen en –kansen- Het aan het licht brengen van noden en beperkingen van de stakeholders- Het analyseren van ede noden van de stakeholders om de

benodigdheden voor een oplossing te definiëren- Het beoordelen en valideren van potentiële en huidige oplossingen- Het managen van ‘het product’ of requirements scope

De laatste tijd komt er in elke doeltreffende oplossing voor een bedrijfsprobleem altijd een softwarecomponent aan bod. Dit samen met veranderingen in de procedure (procedure changes) en mogelijk meer job verantwoordelijkheid (job responsibility).

Business Analysis ↔ Software Development

De meeste ‘software development methodologies’ zijn gecreëerd door software ontwikkelaars om organisaties te helpen om efficiëntere toepassingssystemen te bouwen.Er zijn maar weinigen van hen die business analysis integreren in die ontwikkeling, of zelfs maar het primaire werk ervan herkennen!Een business analyst komt van IT of van Business.

Een Business Analyst moet iemand zijn die gedreven kan werken. Wat zorgt ervoor dat je een fantastische business analist bent?:

1. Wees een opmerkelijk communicatiepersoon2. Versta de algemene bedrijfsconcepten en wees in staat om voor het bedrijf te pleiten3. Zorg dat je een kennis hebt van technologie4. Geniet van gedetailleerde research en registratie5. Wees bekwaam om grote hoeveelheden informatie in verschillende formaten te

organiseren en te managen6. Wees flexibel en natuurlijk nieuwsgierig, en geniet om nieuwe business domeinen te

ontdekken7. Begrijp het software development process

61

8. Wees in staat om je door complexe bedrijfsproblemen te worstelen en om de kernoorzaak van een probleem te bepalen

9. Kom voorbereid met technische hulpmiddelen om excellente eisen te presenteren, te analyseren en de presenteren.

62

Chapter 9 – Building an Information architecture

Architectuur wordt hier bedoeld als: de organisatie van een systeem, dat verdeeld is in componenten, de relatie tussen de verschillende componenten en de relatie met de omgeving. Het gaat ook om de principes die het ontwerp leiden en de evolutie van de omgeving volgen.

Introductie

Managementproblemen:

* Hoe link ik informatie architectuur aan processen in een bedrijf?

* Welk instrument gebruik ik om informatie te modelleren?

* Hoe ontwerpen we informatie architectuur voor een intranet?

* Hoe kunnen onze informatiesystemen samenwerken?

* Hoe kan ik een beleid ontwikkelen voor de beveiliging van informatie?

Wat is informatie architectuur?

De blauwdruk van het volledige systeem waarop alle andere aspecten gebouwd zijn, databank, functies, besturing, interface, interactie, visueel ontwerp. Heel het systeem in kaart brengen dus.

Het is de term om de structuur van een systeem te beschrijven, de manier waarop informatie gegroepeerd is, de manier waarop je van de ene naar de andere applicatie gaat, welke schermen mekaar opvolgen, en welke terminologie gebruikt wordt.

Een effectieve informatie architectuur komt voort uit duidelijke doelstellingen en beperkingen binnen de onderneming, de inhoud en de vereisten van degenen die het systeem zullen gebruiken.

Het is de bedoeling dat de gebruikers op een logische manier door het systeem kunnen gaan om vlot de informatie te vinden die ze nodig hebben.

Gestructureerde gegevens blijken sneller, goedkoper en beter te zijn en zijn van groot belang in een software intensief systeem.

63

Afbeelding:

Een informatie architectuur wordt aangedreven door strategieën betreffende informatie systemen, informatie management en kennis management. De informatie hangt af van strategisch belang.

Vervolgens moet gekeken worden welke de gebruikers zijn en welk het doel is van de informatie architectuur => wat de vereisten zijn

De vereisten kunnen opgedeeld worden in 3 soorten analyses:o Systeemanalyse: wat moet het systeem doen om aan de vereisten te voldoeno Veiligheidsanalyse: welke data het systeem nodig heeft en hoe de data beveiligd kan

worden, en wat de gevolgen zijn indien de veiligheid niet meer intact is.o Interoperationele analyse: welke systemen moeten samenwerken binnen de

organisatie en met partnerorganisaties en wat de vereiste standaards zijn. Het ontwerp van de informatie architectuur kan opgedeeld worden in 3 componenten:

o Systeemontwerp: het ontwerp van het systeem, de vereisten volgend en de resultaten van de analyse gebruikend.

o Veiligheidsontwerp: het ontwerp van de infrastructuur en het beleid om data en systemen te beschermen.

o Interoperationeel ontwerp: het ontwerp van een informatie architectuur dat toegepast kan worden in verschillende software toepassingen en IT platforms.

De laatste stap is de implementatie, het behoud en de controle/evaluatie van de informatie systemen die de architectuur gebruiken, met feedback naar analyse fase.

Informatie architectuur strategie

64

Wat nodig is om de informatie architectuur te coördineren binnen de organisatie, het ruimere kader. De strategie bevat:

* doelstellingen van hoe de informatie architectuur de reeds gedefinieerde strategieën van de onderneming ondersteund.

* de relatie tussen informatie architectuur en de vereiste systemen.

* details over de integratie van technologie

* procedures om data en informatie te gebruiken.

Systeemanalyse

Systeemanalyse is het proces waarin onderzocht en geïdentificeerd wordt wat de vereisten van de organisatie en van de eindgebruiker zijn. Hoe het werkt, wat het probleem met het huidige systeem en wat de verdere vereisten zijn voor het nieuwe systeem. In een informatiemodel wordt de informatie (die de systeemanalist krijgt van de gebruikers en de organisatie) steeds specifieker gedefinieerd, van een algemene behoefte tot een duidelijke, rationeel gedefinieerde behoefte.

Systeemanalist

Een systeemanalist is iemand die zowel weet wat er omgaat in het bedrijf (en daar kritisch over kan reflecteren) als weet hoe je met computers moet omgaan. Hij zet bedrijfs- en informatievereisten om in computergebaseerde informatiesystemen en computertoepassingen die toegepast worden door verschillende technische specialisten zoals computerprogrammeurs. Hij is eigenlijk een ‘bedrijfsproblemenoplosser’.

Basiselementen van een systeemanalyse

Informatiearchitectuur vereisten opsporen

Dit gebeurt door onderzoek. Dit onderzoek gaat over het volgende:

- Context: de bedrijfsdoelen, kapitaalfondsen, politiek, cultuur, technologie en arbeidskrachten.

- Inhoud: data, soorten informatie, objecten, volume en structuur

65

- Gebruikers: publiek, taken, behoeften, het gedrag van informatie, ervaring en woordenschat.Het gebruik van de resultaten van het onderzoek

Men moet analyseren welk het verschil is tussen de data en informatie die momenteel beschikbaar is, en de nieuwe informatie en kennis die ze nog nodig hebben. Ook moeten relaties tussen bepaalde groepen informatie opgespoord worden. Men moet schema’s maken waarop duidelijk is hoe de informatie loopt (information flow diagrams). Men moet ook weten waar in het bedrijf welke informatie opgeslagen wordt.

Identificatie van stakeholders

Het zijn de stakeholders waarvan je informatie nodig hebt (door interviews ed). Er dient een onderscheid gemaakt te worden tussen interne en externe stakeholders, want hun behoeften worden op een verschillende manier benaderd. Voorbeelden van interne stakeholders zijn: eigenaar, gebruiker, ontwikkelaar, ontwerper, opdrachtgever,… van het systeem. Voorbeelden van externe stakeholders zijn: de verkoper, degene die de server voorziet, de planner, onderaannemer,…

Vragenlijsten

Vanzelfsprekend een lijst met vragen, die opgesteld wordt om informatie te bekomen voor het onderzoeksdoel. Het is belangrijk in welke volgorde de vragen worden opgesteld. Vragenlijsten zijn een handig middel om informatie te verkrijgen, indien de onderzoeker precies weet wat hij te weten moet komen en hoe hij de variabelen moet meten. Het is belangrijk in het achterhoofd te houden dat de vragen zo moeten opgesteld worden dat alles duidelijk is voor de invuller, aangezien zijn antwoord een belangrijke invloed heeft op de ontwikkeling van het systeem. Vermijd lange vragen en lange vragenlijsten, vermijd vragen die een antwoord in een bepaalde richting suggereren. Je kan ook open vragen stellen, bv. Wat vind je niet goed aan het huidige informatiesysteem. Gesloten vragen dwingen de respondent te kiezen uit een lijst met gegeven antwoorden. Deze vragen maken dat de respondent sneller beslissingen kan maken, sneller kan antwoorden, en dat de onderzoeker de antwoorden sneller en gemakkelijker kan analyseren.

Interviews

Interviews volgen vaak na een vragenlijst. Hierbij worden vragen mondeling gesteld en mondeling beantwoord. Ook hier is het van belang welke structuur en volgorde de vragen hebben. Er zijn 3 categorieën interviews:

gestructureerde interviews: de vragen en de volgorde ervan zijn op voorhand vastgesteld en de interviewer wijkt daar niet van af tijdens het interview.

semi-gestructureerde interviews: een aantal vragen zijn op voorhand vastgelegd, maar er is nog ruimte voor de interviewer om tussendoor extra vragen te stellen.

66

open interviews: de interviewer komt naar het interview met een aantal onderwerpen die hij wil bespreken.

Voordelen van interviews:

- De kans op bruikbare informatie is zeer hoog door de interactie- Onduidelijkheden kunnen verduidelijkt worden- Je kan het verloop van de vragen opvolgen

Nadelen van interviews:

- Het neemt veel tijd in beslag waardoor je het met minder respondenten moet stellen.- Het verwerken van de informatie duurt ook veel langer- Kan hoge kosten met zich meebrengen- De interpretatie van de antwoorden hangt af van de interviewer.

Observatie

Een manier om informatie te begrijpen is door te observeren hoe de informatie gebruikt wordt in de organisatie met het huidige informatie systeem. Op deze manier is het mogelijk om te begrijpen waarom gebruikers op een bepaalde manier omgaan met informatie, in de context van het huidige informatiesysteem. Om te verzekeren dat de observatie representatief is voor het onderzoek, moet de onderzoeksmethode en de geobserveerde mensen gevalideerd worden op voorhand! De volgende vragen moeten gesteld worden:

- Weten de gebruikers dat ze geobserveerd worden en welke invloed heeft dit op de resultaten?

- Is de gekozen sample van gebruikers representatief voor de hele populatie van gebruikers?- Zullen de gebruikers hun dagdagelijkse taken uitvoeren of taken speciaal uitgekozen voor het

onderzoek?Om de resultaten vast te leggen kunnen tabellen gebruikt worden of videocamera’s.

Audit van documentatie

Als je onderzoekt welke output er op het moment uit het huidige systeem komt, weet je ook al min of meer wat er van het volgende systeem verwacht wordt (maar dan beter). De soorten documenten die in zo’n output onderzocht zullen worden zijn:

- Handleidingen voor het huidige systeem- Hetgeen momenteel gebruikt wordt om informatie op te vangen (papier of elektronisch)- Zaken die op internet beschikbaar zijn over informatiesystemen, zoals statistieken, soorten

query’s, aantallen en soorten van inputs en outputs (bv rapporten).- Documentatie die bedoeld is voor publicatie- Het veiligheidsbeleid en richtlijnen die momenteel in gebruik zijn.

Systeemdiagrammen

67

Het systeemanalyse proces kan afgerond worden door in een diagram weer te geven welke data, informatie, objecten en relaties ertussen er zijn. Het gaat hier om information flow diagrammen (IFD), data flow diagrammen (DFD), en entity relationship diagrammen (ERD).

>>>Wat je moet doen als analyst:

gedraag je als een detective: wees nieuwsgierig, neutraal, aanvaard niet ‘we hebben altijd al zo gewerkt.’, werk beperkingen weg, besteed aandacht aan details, wees creatief!

Om de wereld van de gebruikers te begrijpen hebben we nodig:

Modellering van de schrijftaal (om te kunnen communiceren wat we hebben geleerd van de gebruikers)

Modellering technieken (om zeker te zijn dat we de schrijftaal correct gebruiken) Gevoeligheid van mensen (om zeker te zijn dat we de behoeften van de gebruikers

correct interpreteren, interview- en luistervaardigheden)

Wat is modelleren?

Een model is een vereenvoudigde weergave van een ingewikkelde werkelijkheid, opgesteld om die ingewikkelde werkelijkheid te kunnen begrijpen en de eigenschappen van die realiteit te kennen om het probleem te kunnen oplossen. Modelleren is het tekenen van een of meer grafische voorstellingen van een systeem. Deze grafische voorstellingen helpen bij het visualiseren en analyseren van het probleem, bij het opstellen van vereisten en om informatie systemen te ontwerpen. Een geschreven woord is een goede manier om te communiceren, maar niet altijd de beste manier om de vereisten voor een computer systeem weer te geven beter symbolen! Modelleren is nodig om de situatie weer te geven vanuit verschillende standpunten (vanuit de processen van de onderneming, vanuit wat je moet doen in welk geval, of vanuit de data).

Informatiestroomdiagram (DFD)

De eerste stap in de modellering van de informatie, verkregen uit voorgaande onderzoeksfases, is het tekenen van een informatiestroomdiagram. De analist tekent dit diagram om te weten hoe informatie door de onderneming stroomt, of tussen de onderneming en de buitenwereld. Dit diagram geeft de bron en de bestemming aan van informatie, die een departement, een categorie of een gebruiker kan zijn. Een pijl geeft de informatiestroom weer, met een beschrijving erbij van welke de informatie is die van de bron naar de bestemming stroomt.

68

Bijvoorbeeld:

Op deze manier heeft de analist een idee welke inputs en de outputs, en welke interne en externe actoren betrokken zijn bij de informatiestroom.

Informatiestromen zijn altijd pijlen die in slechts 1 richting gaan, en pijlen die geen naam hebben zijn betekenisloos. Informatie die in 2 richtingen gaat wordt weergegeven door 2 pijlen die ieder in 1 richting gaan. Anders weet je niet precies welk deel van de informatie in de ene en welk deel in de andere richting gaat. De naam van de pijl moet dus ook opgesplitst worden.

Het is ook belangrijk te weten dat in een informatiestroom INFORMATIE stroomt en GEEN PAPIER of geen document! Dus een order stroomt er wel door, maar niet een orderbriefje! Want een orderbriefje bevat meer dan alleen de benodigde informatie over de order (bv de naam en het adres van degene die een order plaatst, wanneer de producten geleverd en betaald moeten worden, de datum waarop de order geplaatst werd, enzovoort) Dit is allemaal niet nodig, in de informatiestroom

69

stroomt enkel het deeltje over welke producten er besteld zijn. Je kan wel met een extra symbool aangeven van welk document de informatie afkomstig is.

Er wordt dus niet weergegeven WANNEER info doorgegeven wordt en op welke MANIER. Met deze diagrammen moet de analist dan naar de gebruikers gaan om te controleren of hij alles wel goed begrepen heeft, hoe alles te werk gaat.

Datastroomdiagram (DFD)

Dit is een grafische weergave van een systeem in de vorm van een diagram, waarbij je niet enkel kijkt naar de informatie, maar ook naar de processen die data omzetten in informatie. Het is dus een gedetailleerdere vorm van het informatiestroomdiagram. We kunnen een DFD uiteenhalen tot op het niveau dat we niet meer verder kunnen onderverdelen in subsystemen. Het uiteindelijke diagram dat je dan krijgt is het model voor het nieuwe systeem.

Er zijn twee soorten DFD’s:

1. Fysische datastroomdiagrammen: hangt af van wie het gebruikt, er worden departementen, mensen,… betrokken in het systeem

2. Logische datastroomdiagrammen: hangt niet af van wie het gebruikt, er wordt enkel getoond wat er gebeurt en niet zozeer hoe het gebeurt (door wie/wat).

Je zou 4 DFD’s kunnen tekenen: een fysisch en logisch voor de huidige situatie: wat het systeem doet en hoe het gebeurt, en een fysisch en logisch voor hoe het nieuwe systeem zou moeten worden: wat het zou moeten doen en hoe dat zou moeten gebeuren.

huidig fysisch DFD

huidig logisch DFD

vereist fysisch DFD

vereist logisch DFD

Beide DFD’s zijn van boven naar onder georiënteerd, eerst wordt een algemene situatie ontwikkeld, en later worden steeds meer componenten en details toegevoegd.

70

In een DFD zijn de volgende dingen opgenomen:

- De bron en de bestemming van de informatiestromen, dit zijn externe entiteiten en bevinden zich buiten de grenzen van het systeem. Het kunnen personen, departementen, organisaties of andere systemen zijn. Een entiteit kan enkel informatie opvragen of verzenden, maar kan zelf geen informatie invoeren in het systeem! De naam wordt geschreven in drukletters. Bv KLANT, VERKOOPSDEPARTEMENT, MANAGER, LEVERANCIER, BANK,…

- De processen die data omzetten in informatie, dit zijn de functies van het systeem. Een proces heeft een nummer in de linker bovenhoek. Die heeft niets met chronologie te maken, want verschillende processen kunnen tegelijkertijd uitgevoerd worden, de nummer is de ‘naam’ van het proces. Een fysische locatie (departement, persoon die het uitvoert,…) staat in de rechter bovenhoek en een beschrijving van het proces onderaan. Dat een proces voorkomt op een diagram, wil niet altijd zeggen dat het uitgevoerd wordt, er zijn processen die slechts in werking treden in bepaalde gevallen, bijvoorbeeld problemen met betalingen. Voorbeelden van namen voor een proces zijn: voorbereiding factuur, berekening salaris, aanvaarding artikelen,…

- De informatie of data die in, door en uit het systeem stroomt, weergegeven door een pijl. De pijlen die dezelfde naam dragen moeten exact dezelfde informatie vervoeren. Voor alle andere dingen (data stores, processen,…) moet een unieke naam bedacht worden.

- De manier waarop informatie opgeslagen wordt in het systeem, een verzameling van informatie die nodig is bij een bepaald proces (dus niet een gehele databank, maar slechts een stukje daarvan). Bv een bestand op een disk, een tabel in een database, een boek, een blad papier,… Het gaat dus om een fysische opslagplaats, dit kan een kaft zijn, een Excel bestand,… Sommige data stores zijn tijdelijk, namelijk voor de duur van het proces. Als ze niet meer nodig zijn worden ze vernietigd. Voorbeelden van namen voor data stores zijn klant, rekening, student, artikel,… (of in meervoud).

Dit zijn de symbolen:

(voor een bron of een bestemming (entiteit) wordt ook vaak een rechthoek gebruikt)

Deze 4 elementen zijn verplicht aanwezig in een DFD. Er zijn echter ook extra elementen die we kunnen toevoegen, zoals een notitie (ter verduidelijking) of een bronnenstroom (bv papieren rapporten, waarvan de informatie afkomstig is, maar daar staat dus meer informatie op dan je nodig hebt. Bijvoorbeeld als je als informatiestroom stuurt ja of nee, dan kan je daarnaast nog een bronnenstroom sturen waarin staat waarom juist ja of nee. De symbolen die voor deze extra elementen gebruikt worden zijn:

71

een notitie link of een proces specificatie verbonden aan het betreffende object en een dubbele pijl voor een bronnenstroom:

Processpecificaties zijn vooral nuttig voor de programmeurs, niet zozeer voor de gebruikers.

Dit is een voorbeeld van een DFD:

72

Er zijn regels voor DFD’s:

- Een proces kan nooit enkel inputs hebben (zwart gat), als het enkel inputs heeft, is het een bestemming (sink). Een proces kan ook nooit enkel outputs hebben, anders zou het data aanmaken uit het niets. Als het enkel outputs heeft is het een bron.

- Data kan nooit van de ene opslagplaats rechtstreeks naar de andere opslagplaats stromen, dat moet altijd via een proces. Data moet altijd via een proces bewegen naar eender welk symbool (bron, bestemming, opslagplaats).

- Data kan ook nooit rechtstreeks van een bron naar een bestemming stromen, dat moet altijd via een proces. Anders wordt die stroom niet weergegeven op het DFD.

- Dezelfde data (1 stroom) kan op hetzelfde moment toekomen in 2 verschillende processen, data stores of bronnen of bestemmingen. Dit wordt weergegeven met een ‘vork’ in de pijl.

- Er kunnen ook 2 verschillende datastromen op hetzelfde moment toekomen in 1 locatie.- Een datastroom kan nooit rechtstreeks terugkeren naar het proces waar het vandaan komt,

dit moet altijd gebeuren via een ander tussenproces.- Een datastroom naar een datastore betekent een update van de gegevens die daar

opgeslagen zijn. - Een datastroom die uit een datastore komt betekent dat je die data gebruikt voor je proces.

73

DFD’s kunnen eenvoudig zijn, maar meestal zijn ze zeer complex:

In zo’n geval kan het zijn dat datastromen elkaar kruisen. Dit moet je dan weergeven met een boogje:

Het kan ook zijn dat je een bepaalde data opslagplaats of een bepaalde entiteit best nog een keer opnieuw weergeeft op een andere plaats om het overzichtelijk te kunnen houden. Dan duidt je op deze entiteiten ook best aan dat ze elders nog eens voorkomen, bijvoorbeeld als volgt:

74

Op deze manier zou je eventueel ook kruisende pijlen kunnen vermijden; Entiteiten teken je best aan de rand van je blad om het overzicht te behouden, en het kan best zijn dat je een aantal keer opnieuw moet beginnen tekenen vooraleer je een overzichtelijk diagram bekomt.

Een andere manier om ingewikkelde DFD’s toch duidelijk te kunnen weergeven is door ze uiteen te halen in verschillende niveaus. Dit komt vaak voor, omdat je echt wel zeker moet zijn dat ALLE informatie erop staat. Je werkt volgens een hiërarchische structuur die bestaat uit een aantal verbonden diagrammen. De verschillende niveaus zijn:

- een context diagram: level 0, bevat 1 proces en wat daar rond gebeurt, maar niet zo gedetailleerd, enkel de stromen tussen het proces en de externe entiteiten, geen opslagplaatsen.

- een 1st level diagram: het bevat alles van het context diagram, plus data opslagplaatsen, maar dan voor een groter aantal processen.

- een 2nd level diagram: bevat nog meer processen, gedetailleerdere processen (1.1, 1.2, 1.3,…). Het maximum aantal processen in 1 diagram is gelimiteerd tot 10, want meer krijg je er niet op een blad…

75

Zo kan je dan meerdere ‘stukjes’ met elkaar verbinden.

Richtlijnen voor het tekenen van een DFD

Identificeer de input en de output van het systeem (input afleiden uit de output). Dit is meestal informatie uit documenten.

Identificeer de processen die input nodig hebben en output produceren. Teken de datastromen en de externe entiteiten(aan de rand van je blad). Teken voor elke datastroom op het diagram het proces dat de data zal ontvangen of

produceren. Teken voor elk proces een bijbehorende data opslagplaats en de datastromen

daartussen. Teken extra processen en datastromen en opslagplaatsen indien nodig. Controleer of alles er op staat en je aan de regels voldoet.

Dingen die je in een processpecificatie kan zetten zijn bijvoorbeeld een ‘beslissingsboom’:

Of:

76

Of een beslissingstabel:

Vaak maak je best zowel een beslissingsboom en een beslissingstabel, om zeker te zijn dat je niets vergeten bent.

Voorbeelden en oefeningen: zie eigen notities (ik ga die niet overtekenen op de computer ze! )

Entiteiten relaties diagram (ERD)

Een ERD is evenzeer een instrument om data te modelleren. Een ERD geeft alle data weer die in een informatiesysteem ingestoken, opgeslagen, omgevormd en geproduceerd worden. Het focust enkel op data (niet op processen). Het gaat over gegevens en de relatie tussen gegevens.

OPGELET: entiteiten uit een DFD zijn niet dezelfde als entiteiten uit een ERD!! (andere definitie!)

77

*Een entiteit is een ‘ding’ dat op zichzelf kan bestaan en uniek gedefinieerd kan worden. Het is een stuk data dat kan beschouwd worden als een geheel. Het kan een persoon zijn zoals een passagier voor een vlucht, maar ook iets abstract, zoals bijvoorbeeld een vlucht voor een vliegtuig. Het is een ding waarover we informatie zoeken, dat belangrijk is voor het informatiesysteem. Een entiteit wordt weergegeven door een woord in drukletters in een rechthoek. Dat woord geeft niet 1 ding weer, maar een verzameling (ook al staat het in enkelvoud).

Het gaat dus niet om 1 klant, maar om de verzameling klanten van dat bedrijf. Een entiteit bestaat altijd uit meerdere dingen, als je maar 1 ding erin hebt zitten, is het geen entiteit.

*Een relatie is een verband tussen twee entiteiten. Relaties kunnen in twee richtingen gaan, maar van een verschillende soort zijn in een verschillende richting. Een entiteit kan meerdere relaties hebben. Relaties worden weergegeven door een lijn (evt met kraaienpoten)

*Een entiteit kan attributen hebben. Attributen zijn de gegevens die we verzamelen over de entiteiten. Het zijn een soort ‘kenmerken’. Voorbeelden van attributen bij de entiteit ‘passagier’ zijn: naam, adres, paspoort nummer, geslacht,… Attributen bij de entiteit ‘vlucht’ zijn: vluchtnummer, tijd, datum, bestemming,…

Entiteiten, attributen en relaties zijn de 3 basiselementen in een ERD.

Een attribuut wordt geschreven in kleine letters, elk woord beginnend met een hoofdletter, en dat woord is in een ellips verbonden aan de betreffende entiteit.

Een attribuut is een kenmerk dat van belang is voor de organisatie. Het beschrijft de entiteit. Het is geen verplichting om attributen weer te geven. Als je ze weergeeft is het in dit voorbeeld belangrijk dat je de voornaam en de achternaam niet als 1 geheel ‘naam’ beschouwt, want als studenten hun volledige naam in 1 vak zouden moeten intypen, weet je niet of ze eerst hun voornaam of eerst hun achternaam zullen typen, en dit maakt het moeilijk om de namen alfabetisch te rangschikken. Als je het als 2 afzonderlijke attributen beschouwd, kan je ze wel rangschikken. Een attribuut kan ook nooit een echte naam zoals bv. ‘Joske Vermeulen’ zijn, maar moet altijd een omschrijving zijn, voornaam en achternaam dus.

Attributen kunnen atomair of samengesteld zijn. Een samengesteld attribuut kan je nog onderverdelen in atomaire attributen. ‘Adres’ is bv een samengesteld attribuut, en kan je nog opdelen in ‘straat’, ‘land’, ‘postcode’ enzovoort, welke atomaire attributen zijn.

78

Een attribuut kan 1 waarde hebben, bijvoorbeeld ‘straat’ je woont maar in 1 straat.

Maar het kan ook meerdere waarden hebben, bijvoorbeeld ‘hobby’je kan meerdere hobby’s hebben. Indien dit het geval is, moet je het attribuut weergeven met een dubbele ellips:

Je kan ook ‘berekende’ attributen hebben. Deze waarden kunnen dan berekend worden aan de hand van een ander attribuut. Bijvoorbeeld ‘leeftijd’ kun je berekenen aan de hand van het attribuut ‘geboortedatum’. Men noemt dit een berekend attribuut omdat het geen vaststaand gegeven is, je berekent het op het moment dat je het nodig hebt. (je berekent het verschil tussen de datum van vandaag en je geboortedatum) Indien je Leeftijd als een gewoon attribuut zou beschouwen, zou dat willen zeggen dat je voor eeuwig en altijd dezelfde leeftijd hebt, of dat je dit attribuut voor elke student zou moeten aanpassen elke keer als die een jaartje ouder geworden is. Dit klopt duidelijk niet. Een berekend attribuut mag je nooit in je database terugvinden, een database moet vastliggen. Een berekend attribuut wordt weergegeven door een ellips in stippellijn:

Je hebt ook een ‘identificatieattribuut’. Dit is een uniek nummer, een sleutel, een ID voor elk element van je entiteit. Dit noemt men de ‘primary key’. Deze wordt onderlijnd in het diagram. Er zijn enkelvoudige (atomaire) sleutels, maar ook samengestelde sleutels. Een voorbeeld van een samengestelde sleutel is bijvoorbeeld de sleutel voor de entiteit ORDER DETAILS. Je zou als primary key OrderID of ProductID kunnen nemen, maar deze zijn beide niet uniek genoeg, want een bepaald product kan voorkomen op meerdere orders, en een bepaalde order kan meerdere producten bevatten. Een order is dus afhankelijk van zowel orderID als van ProductID. Daarom vormen zij samen de samengestelde primary key van ORDER DETAILS.

79

Opgelet: kies een primary key die nooit verandert gedurende de gehele levensduur van de entiteit! Een primary key moet een duidelijke waarde hebben, niet ‘onbekend’ of ‘nul’.

Opgelet2: Hoe complexer de samengestelde sleutel, hoe trager je database gaat werken.

Aan een ERD kunnen beperkingen zijn:

Een ISBN nummer is een unieke code voor een boek, en zal daarom als primary key gebruikt worden. Het probleem is hier dat ISBN een moderne uitvinding is, en oude boeken, die nog geen ISBN nummer hebben, zullen niet in dit systeem kunnen worden opgenomen.

In het volgende voorbeeld wordt duidelijk waarom je soms een uniek nummer moet toekennen, omdat de combinatie van bestaande attributen nooit tot een uniek nummer leidt:

Zelfs indien je de voornaam, achternaam en telefoonnummer zou combineren tot unieke code, stoot je op beperkingen: niet iedereen heeft een eigen telefoonnummer (1 voor het hele gezin). Mensen kunnen zelfs dezelfde voornaam en achternaam en geboortedatum en telefoonnummer hebben, bv een jongen die dezelfde naam heeft als zijn grootvader, die bij hen inwoont, en toevallig ook op dezelfde dag geboren is. Het is heel toevallig, maar het kan voorkomen. En indien de combinatie kans maakt om niet uniek te zijn, mag je die niet als sleutel nemen.

80

Er zijn verschillende soorten relaties:

1 op 1 relatie: 1 element uit entiteit A kan slechts een relatie hebben met 1 element uit entiteit B:

Optionele 1 op 1 relatie: 1 element uit A kan slechts een relatie hebben met 1 element uit entiteit B, maar kan ook een relatie hebben met geen enkel element uit entiteit B:

Verplichte 1 op 1 relatie: elk element uit A MOET een relatie hebben met 1 element uit entiteit B niet meer maar ook niet minder:

1 op veel relatie: 1 element uit entiteit A kan in verband staan met meerdere elementen uit entiteit B, bv 1 vliegroute kan gebruikt worden voor meerdere vluchten:

Optionele 1 op veel relatie: 1 element uit entiteit A kan in relatie staan tot meerdere elementen uit entiteit B, maar dit hoeft niet, het kan ook in relatie staan tot slechts 1 of zelfs geen element uit entiteit B, bijvoorbeeld een moeder kan zonen hebben, maar ze kan ook geen zoon hebben en allemaal dochters:

Verplichte 1 op veel relatie: 1 element uit entiteit A MOET in relatie staan tot veel elementen uit entiteit B of toch minstens met 1, bijvoorbeeld een kind heeft altijd een moeder (gehad):

81

Een veel op veel relatie kan je niet tekenen in een ERD, omdat een databank dit niet kan verwerken (je komt in een oneindige lus terecht) dat moet je dan opsplitsen in 2 keer een 1 op veel relatie, met daar tussen een tussenentiteit. De ‘veelkant’ moet altijd staan bij de tussenentiteit. Een voorbeeld van een ERD met meerdere relaties:

De attributen worden aan de entiteiten toegevoegd. De primary key van een tussenentiteit bestaat altijd uit de gecombineerde sleutels van de twee entiteiten waar een veel op veel relatie tussen

bestaat. wil zeggen dat 1 werknemer kan meedoen aan meerdere projecten, maar dat er ook

werknemers kunnen zijn die aan geen enkel project meedoen.. wil zeggen dat aan 1 project meerdere mensen kunnen meedoen, maar dat je minstens 1 werknemer moet hebben per project, want zonder werknemers geen project. Zoals je ziet gaat de relatie nog steeds tussen project en werknemer, het wordt wel weergegeven met een tussenentiteit, maar dit is enkel om de relatie overzichtelijker te maken. Die tussenentiteit legt vast welke werknemer er juist meedoet aan welke projecten.

Een foreign key is een sleutel die bij een entiteit hoort, maar die verwijst naar de unieke code van een andere entiteit. Bijvoorbeeld werknemer is een entiteit, en heeft een werknemerID, dit is een uniek kenmerk per werknemer. Een functie is ook een uniek kenmerk per werknemer, maar ‘functie’ is ook een entiteit (want die heeft kenmerken). Bij de entiteit ‘werknemer’ zal een foreign key staan van ‘functie’, wat erop wijst dat als je wil weten welke functie die werknemer heeft, dat je dan moet gaan kijken in de tabel met functies, daar zal je de details van die functie terugvinden. Bij de entiteit werknemer zal je dus niet weten welke functie die werknemer heeft, je kan enkel de code zien die bij die functie hoort, en in de tabel ‘functie’ moet je dan gaan zien welke functie er juist bij die code

82

hoort. Met andere woorden, de relatie tussen werknemer en functie verloopt via de sleutel FuctieID, en vertrekt vanuit de primary key en komt toe in de foreign key.

Een werknemer kan maar 1 functie hebben, daarom is FunctionID een unieke code voor functie. Er kunnen ook werknemers zijn die geen functie hebben, vandaar de 0 aan de kant van employee. En er kunnen ook functies zijn die door niemand ingevuld zijn, vandaar de 0 aan de kant van function.

1 tabel kan meerdere foreign key’s hebben.

Een primary key en de overeenkomstige foreign key moeten van hetzelfde type zijn, bijvoorbeeld allebei een nummer van evenveel cijfers.

Er kunnen ook relaties zijn tussen elementen uit dezelfde entiteit: een relatie van een entiteit naar zichzelf.

Figuur 1: 1 persoon uit entiteit Persoon kan getrouwd zijn met 1 persoon uit dezelfde entiteit, maar kan ook met geen enkel persoon uit die entiteit getrouwd zijn. Vandaar de nullen in beide richtingen (de relatie is in beide richtingen hetzelfde).

Figuur 2: Als je de baas bent, heb je niemand boven je, vandaar de 0 links van employee. Je hebt als baas wel veel mensen onder je, vandaar de kraaienpoot rechts van employee, maar je kan ook niemand onder je hebben, vandaar de 0 rechts van employee. Van links naar rechts: 1 op veel: 1 diensthoofd heeft meerdere mensen onder zich, van rechts naar links: je werkt maar voor 1 baas.

83

Een foreign key die verwijst naar een primary key die zich in dezelfde entiteit bevindt, zoals in figuur 2, wordt onderlijnd met een stippellijn ipv een volle lijn.

Opmerking: je moet enkel relaties tekenen die betekenisvol zijn. Overbodige relaties moet je vermijden:

In deze tekening is de rechtse relatie overbodig, want die zit al verwerkt in de relaties aan de linkerkant. Je weet al dat een land inwoners heeft, omdat inwoners ineen stad wonen, en steden maken deel uit van een land, dus inwoners wonen in een land. Die rechtse relatie moet je dus weglaten.

84

In dit geval is de rechtse relatie niet overbodig, want als je zegt dat een land cricket spelers heeft, weet je nog niet in welke stad die wonen. Er zijn ook steden die geen cricket spelers hebben. Die relatie moet je dus wel tekenen.

Om verwarring te vermijden kan je best in het begin een naam geven aan de relaties, zo weet je welke nodig zijn en welke niet.

Voorbeelden en oefeningen: zie eigen notities.

85

Informatiemanagement: Hoofdstuk 9: UML

Factoren die het succes van een project beïnvloeden* Succesvol project = als het project voldoet aan de noden van de klant + binnen het juiste budget + binnen de juiste tijd. Maar: tijds- en budgetaspect zijn minder belangrijk. Het hoofdargument voor een succesvol project is dat het voldoet aan de wensen van de klant.

* Niet – succesvol project: - het project wordt afgeblazen vooraleer men het heeft kunnen leveren- als men niet kan leveren wat de klant verwacht binnen het opgestelde budget- als men het verkeerde systeem ontwikkeld en levert- als de kwaliteit van het product niet voldoet en het dus niet kan gebruikt worden door de klant- als het product veel te laat geleverd wordt- als het te duur wordt om te ontwikkelen en dat de klant het niet meer kan betalen

Verschil tussen België en Amerika: in Amerika gaat men veel sneller niet – succesvolle projecten afbreken terwijl men in Europa eerder de neiging heeft om proberen te redden wat er te redden valt.

Standish Group: publiceert elk jaar een rapport met de kenmerken waaraan succesvolle projecten volgens hen moeten voldoen.Uit het rapport van 1994 kan men het volgende afleiden:

“Challenged” wil zeggen dat het systeem uiteindelijk wel werkte, maar niet volledig was of het was veel te duur.

86

Succesfactoren voor een project % respons1. Betrokkenheid van de klant 15.92. Steun van het management 13.93. Duidelijke omschrijving van de

wensen van de klant13.0

4. Goede planning 9.65. Realistische verwachtingen 8.26. Kleinere onderliggende projecten 7.77. Bekwaam personeel 7.28. Bezittingen 5.39. Duidelijke visie en doelen 2.910. Hard werkend personeel 2.4

Andere 13.9Uit deze resultaten kunnen we dus afleiden dat de belangrijkste factor voor een succesvol project de betrokkenheid van de klant is, wat ook een tevreden klant impliceert. Verder is het ook zeer belangrijk om de steun van het managent achter u te hebben.

Bij de projecten die “challenged” zijn, zijn de voornaamste problemen: - dat het team van analisten niet goed weet wat de klant nu precies nodig heeft omdat de klant zijn wensen moeilijk kan omschrijven. Er is dus zeker nood aan goede communicatie als je wil dat je project slaagt.- dat de klant niet betrokken is bij het ontwikkelen van het project. Als de klant geen interesse toont in de ontwikkelingen en jij ontwikkelt een systeem, kan het voorvallen dat je iets ontwikkeld hebt dat de klant eigenlijk helemaal niet nodig heeft.- dat de bedrijfswereld constant in verandering is. Deze veranderingen moeten dus op een goede manier worden opgenomen in je project anders maak je een systeem dat de klant niet nodig heeft.

De essentie van het ontwikkelen van software* Het ontwikkelen van software/systemen is een creatief proces! Er wordt een creatieve oplossing gezocht voor het probleem van de klant en er zijn dus verschillende mogelijke oplossingen. Er is dus niet iets zoals “1 foute” of 1 “juiste” oplossing voor een probleem.

Kenmerken van een systeem: - Complexity = complexiteit van het systeem- Conformity = conformiteit - Changebility = veranderlijkheid- Invisibility = het deel van het systeem dat onzichtbaar is voor de klant

87

1 Complexity Dit heeft veel te maken met de grootte van het project en het aantal gegevens dat verwerkt moet worden. Hoe meer gegevens, hoe groter het project en hoe complexer het systeem zal worden.

2 ConformityJe moet rekening houden met het platform waarop het systeem moet draaien. Het is dus noodzakelijk dat het systeem op dat platform kan draaien.

3 ChangebilityZoals eerder gezegd, is de bedrijfswereld constant in beweging en moet je je systeem hieraan aanpassen.

4 InvisibilityDit is dus het grote stuk van het systeem dat onzichtbaar is. De gebruiker ziet alleen het scherm en ziet dus niet de achterliggende codes. Voor de gebruiker kan een systeem er heel gemakkelijk en eenvoudig uitzien, terwijl er wel ingewikkelde codes gebruikt zijn. Gebruikers kunnen daarom soms ook onmogelijke dingen vragen. Ze weten niet wat er schuilgaat achter het systeem en simpele vragen van de gebruikers kunnen soms echter onmogelijk zijn om te ontwikkelen.

* We mogen echter niet vergeten dat het ontwikkelen van software door mensen gebeurt, het is dus ook een sociaal proces. Hierdoor kunnen er zich wel een aantal problemen voordoen die we kunnen indelen in 3 groepen: - Stakeholders = alle belanghebbenden ( gebruikers, ontwikkelaars, opdrachtgevers, …)- proces- modellering (modeling)

Variabele 1: stakeholdersInformatiesystemen zijn sociale systemen: ontwikkeld door mensen, voor mensen. Er kunnen dus ook fouten gebeuren, zowel bij de consument, als bij de ontwikkelaars.

Door de consument kunnen projecten falen als- De wensen van de klant verkeerd worden begrepen: gebruikers kunnen hun wensen niet altijd even goed onder woorden brengen.- De klant zijn wensen constant verandert en constant van idee verandert- Gebruikers op voorhand gekant zijn tegen een nieuw systeem, is dit meestal een garantie voor mislukking. Bv: personeel werkt al jaren met hetzelfde systeem en wil niet dat dit verandert.

Voor de ontwikkelaars gelden de volgende regels: - Goede, gekwalificeerde ontwikkelaars gebruiken- ontwikkelaars moeten nauwgezet werken - TEAMWERK! ontwikkel een systeem nooit alleen

88

Variabele 2: ProcesHet proces bepaalt de activiteiten en de procedures die in de ontwikkeling van de software gebruikt worden. een procesmodel moet: - een order voor uitgaande activiteiten bezitten- specificeren welke ontwikkelingen er gedaan moeten worden en wanneer deze gedaan moeten worden- ontwikkelingen toeschrijven aan ontwikkelaars- criteria aanbieden om de voortgang van het project te meten, de resultaten te meten en om verdere projecten te plannen. een procesmodel is UNIEK voor elke organisatie, en kan dus niet gestandaardiseerd worden.

Variabele 3: ModelleringUML is een modelleertaal en gaat dus niet uitleggen hoe je je systeem moet ontwikkelen! Dit is iets wat de analist zelf beheerst. Hij beslist hoe hij die taal gaat gebruiken en welke processen ontwikkeld worden.

De UML-modellen kunnen ingedeeld worden in 3 groepen- state models: structuur van de databank weergeven- behaviour models: gedrag van het systeem uitleggen en tonen hoe alle componenten samenwerken- state change models: geven de wijzigingen van een systeem weer

Systemen voor 3 niveaus van management

1 Operationeel: = systemen die enorm veel gegevens verwerken en de dagelijkse systemen uitvoerenIT – oplossing = databank

2 Tactisch: = systemen die de gegevens omzetten in informatie: ze halen er die gegevens uit die de gebruiker nodig heeft.IT – oplossing = data warehouse = een aparte databank die gevoed is met samengevatte gegevens uit de grote systemen. Je kan hier geen detailinfo uit halen, maar meer algemene info.

3 Strategisch:= expertsystemen: werken met informatie waar men eigen kennis en ervaring aan toevoegt en zo komt men tot kennis.IT – oplossing = knowledge management

System development life cycle ( = levenscyclus voor het ontwikkelen van een systeem)

89

Een complex systeem ga je niet in 1 keer aanvatten, maar opsplitsen in verschillende modellen.De levenscyclus bepaalt: - de toegepaste modellering- de exacte fases dat het systeem doorloopt- de methodologie en het geassocieerde ontwikkelingsproces: welk proces er wanneer wordt uitgevoerd.

Development approach (= benadering van de ontwikkeling)Applicaties zijn veel meer interactief geworden: het is de gebruiker die de controle heeft over het systeem. Vroeger werden systemen ontwikkeld met een gestructureerde benadering, maar omdat de systemen nu veel interactiever zijn, wordt vandaag de dag de objectgeoriënteerde benadering gebruikt = object approach.

Waarom modelleersystemen?

De betekenis en het gebruik van de symbolen van de modelleertaal, moet je leren. Bv: als je deze afbeelding aan een kind laat zien, zien zij alleen een hert, hoewel het bord eigenlijk betekent: opgelet, overstekend wild. Een kind legt de link tussen het hert en het wild niet. Voor hen zou er dus ook een bord moeten bestaan waarop een egel, een zwijn, … staat.

Modellen worden vaak ontwikkeld in de context van een bedrijf en IT-systemen met de bedoeling om de huidige of toekomstige systemen beter te begrijpen. Toch komt een model nooit volledig overeen met de realiteit! Modelleren betekent altijd: de nadruk leggen op de essentiële details en al het overbodige weglaten. Maar: wat is essentieel en wat is overbodig?Het antwoord op deze vraag hangt af van de welke doelen het model heeft en wie het model

90

ziet/leest. Des te meer informatie dat een model moet bevatten, des te ingewikkelder en moeilijker dat het wordt.

De tekening hierboven wordt gebruikt om aan te tonen dat als je iets verandert, je dan al je modellen moet aanpassen om ze te doen kloppen met de realiteit.Bv: als er 1 aspect van de kubus wijzigt, moet je ook al je modellen wijzigen, anders kloppen ze niet meer! Als de kubus wijzigt, wijzigen vooraanzicht, zijaanzicht en bovenaanzicht ook.

Modellen zijn vereenvoudigingen die de belangrijkste details weergeven van een complex probleem of een complexe structuur. Dit doen ze door de irrelevante dingen weg te laten.Modellen helpen ons om dingen te organiseren, visualiseren en te begrijpen.

Methodes en modelleertalenUit wat we hierboven gezegd hebben weten we dat een model een representatie is die de belangrijkste componenten bevat van het ding dat gemodelleerd wordt en dit bekeken vanuit een bepaald standpunt. Dit wordt bereikt door alleen de essentiële dingen te op te nemen en de irrelevante dingen weg te laten.Een model van een software systeem wordt altijd in een modelleertaal gemaakt.

Modeling Maturity Levels (MML’s)Elk systeem dat je moet ontwikkelen kan je indelen in verschillende niveaus: en per niveaus zijn er modelleertalen die je kan gebruiken. Immers, een modelleertaal is pas geschikt om te gebruiken als de taal dicht genoeg bij het te ontwikkelen systeem ligt.Niveau 0: geen specificatiesNiveau 1: tekstNiveau 2: tekst en diagrammenNiveau 3: Modellen met tekstNiveau 4: precisiemodellenNiveau 5: alleen modellen

91

Object georiënteerde modellering ( Object – Oriented modeling) = OO – modelingHet object georiënteerd programmeren is ontwikkeld in de jaren ’60. Het is dus niet iets “moderns” maar het bestaat al sinds een langere tijd.

Het OO – paradigmaEen paradigma = een bepaalde manier van denken en geloven om de manier waarop we kennis benaderen, leren en begrijpen te organiseren. Een paradigma komt voor wanneer we een radicaal andere manier van denken aannemen. bv: de theorie van Darwin over het ontstaan van de mens. De object georiënteerde manier van programmeren zorgde er ook voor dat mensen een heel andere kijk krijgen op de dingen, een volledig ander beeld kregen van de wereld.

Introductie in objectenEen gebruiker van een systeem leeft in een wereld van objecten. Elk object voldoet aan een bepaalde beschrijving. OO: we kijken niet alleen naar de kenmerken van een object, maar ook naar het gedrag van het object. Bv: een trein kan versnellen en vertragen, starten en stoppen met rijden. Objecten hebben dus een bepaald gedrag en reageren op de omgeving. De manier waarop het gedrag wordt uitgevoerd, is eigen aan het object.

Een object is iets uit de wereld van de gebruiker, het heeft bepaalde attributen die het object beschrijven, het heeft relaties met andere objecten en het heeft een gedrag dat het kan vertonen.

David Taylor Donut Diagram

Het gedrag dat het object in dit geval kan vertonen = change name, change adress, change prone nomber, ...

92

Request: je moet verzoeken aan het object customer om het bv het adres onder het element Jo te vervangen door middel van “change adress”. Het object zelf doet dus eigenlijk de aanpassing, want het kan dit gedrag vertonen. Als je een bevel geeft aan het object, moet je dus altijd verwijzen naar het gedrag dat je wenst dat het object vertoont.bv: Jo.Change adress

Interactie tussen objecten = messages (berichten) = de middelen waarmee objecten op elkaar inwerken

Waarom wordt OO gebruikt?Via objecten kunnen we de wereld van de gebruiker veel nauwer in kaart brengen. Zo kunnen analisten systemen ontwikkelen (in de computerwereld) die veel dichter bij de echte wereld staan waarin de gebruiker leeft. Gebruik van data-entiteiten. Een data-entiteit = een ding dat van belang is voor de gebruiker in de echte wereld. Het zijn deze entiteiten die zullen worden opgenomen als objecten in het systeem.

Het OOA – landschapBij OOA is het UML dat wordt gebruikt al codeertaal. UML = “Unified Modeling Language”. Het is een standaardtaal voor het specificeren, visualiseren en documenteren van de verschillende stadia van een object georiënteerd systeem dat men aan het ontwikkelen is. Het vereenvoudigt het complexe proces van het ontwikkelen van software. UML notatie voor communicatie bestaat uit een grafische notering waardoor er duidelijker kan gecommuniceerd worden dan wanneer men gewoon gesproken taal zou gebruiken. Dit heeft als bijkomend voordeel dat UML dus niet gekoppeld is aan een bepaalde taal of een bepaalde technologie. Het kan door iedereen gebruikt worden. Door het gebruikt van UML kan het ontwikkelen van een systeem dus gestandaardiseerd worden. (iedereen spreekt immers dezelfde taal).

The UML4 doelen van UML: - Visualizing (visualiseren) Brengen vooral in kaart welke functionaliteit een proces kan bieden en hoe de verschillende elementen met elkaar in verband staan. - Specifying (specificeren) Alleen de belangrijkste objecten, relaties en gedragingen worden opgenomen in UML-ConstructingForward engeneering: eerst een code generen op basis van een model en die daarna omzetten in een programmeertaalReverse engeneering: een model reconstrueren uit implementatie- Documenting ( documenteren)Soms worden er bij het diagram nog extra documenten bijgevoegd voor extra uitleg. Zo kan

93

er bijvoorbeeld een document zijn die de textuele uitleg bij het model bevat.UML voorziet in een standaard voor het schrijven van een blauwdruk van een systeem.

UML-modellen: 3 groepen:- State models: beschrijven de data structuren- behaviour models: beschrijven de verschillende relaties tussen de objecten- state change models: beschrijven de verschillende stadia van het systeem over de tijd.

UML views en diagrams

UML views

* Use case view: FunctionaliteitGebruikers van een use case kunnen zowel externe klanten zijn als mensen van het bedrijf zelf. Gebruikers van een use case zijn actoren: ze kunnen dus verschillende rollen spelen. Ze kunnen in verschillende rollen gebruik maken van de use case: bv iemand kan het systeem doorlopen als klant, maar ook als boekhouder.

*Logical view: kijken naar hoe alle componenten samenwerken. = relaties tussen ver schillende objecten weergeven en kijken hoe de objecten evolueren door de tijd heen.

*Implementation view: welke componenten er allemaal gebruikt zijn om het systeem samen te stellen. Deze wordt gebruikt door ontwikkelaars.

*Process view: performantie in kaart brengen: welke processen wanneer kunnen uitgevoerd worden.

*Deployment view: geeft de fysische architectuur van het systeem weer.

94

UML Diagrammen

UML misvattingen* UML is gemakkelijk te leren en gemakkelijk te gebruiken UML is heel rijk aan symbolen, maar dit wil dus ook zeggen dat het veel meer regels heeft om die symbolen te gebruiken. Het is dus niet zo gemakkelijk als je op het 1ste zicht zou denken.* UML is compleet Dit is zeker niet juist: er zijn bepaalde dingen die je niet met UML kan ontwikkelenbv: user interface: hoe je je scherm gaat ontwikkelen kan je niet doen met UML* UML genereert een code UML genereert geen code: als je uw UML-modellen ontwikkeld hebt, heb je nog geen werkend systeem* UML bevat modelleermethodes UML is gewoon een taal en je beslist zelf hoe je die taal gaat gebruiken. UML bevat dus zeker geen modelleermethodes.

Analysis phase De modellen uit de analytische fase tonen de vereisten van de gebruiker. wat het uiteindelijke systeem moet DOEN. De output van dit proces is een conceptueel model dat 3 mogelijke uitkomsten heeft:- requirements model (model van de vereisten)- object model ( model van de objecten)- statechart model

95

Het “requirements model” documenteert de noden van de gebruiker zodat het verstaanbaar is voor de gebruiker en dat het bruikbaar is voor de ontwikkelaars als startpunt voor de ontwikkeling van het systeem.De verschillende componenten zijn: - project scope ( het gezichtsveld van het project, wat het project allemaal moet bevatten)- Initial feasibility analysis = 1ste houdbaarheidsonderzoek- Context diagram- Use case script model: functionaliteit vastleggen- Interface descriptions = beschrijving over de interface

The requirements model* Project scope: doel: er zeker van zijn dat de doelen van het systeem de doelen van het bedrijf bevatten.Wat moet een project scope bevatten: - wat het uiteindelijke systeem zal doen- welke functies het systeem bevat- welke gebruikers het systeem gaan gebruiken- wat geen deel zal uitmaken van het systeem* 1ste houdbaarheidsonderzoek: - operationele uitvoerbaarheid: zal het systeem in staat zijn om te werken zoals gevraagd wordt door het bedrijf?- technische uitvoerbaarheid: hebben we de benodigde software, hardware en technische know how om het systeem te ontwikkelen?- schematische uitvoerbaarheid: Is de ontwikkelingstijd die ter beschikking wordt gesteld haalbaar?- economische uitvoerbaarheid: Is het economisch wel haalbaar, kost het niet te veel? Soms is het beter om een systeem gewoon aan te kopen in plaats van het zelf te ontwikkelen. Een systeem ontwikkelen is immers vrij duur.* Context diagram: toont het systeem als een rechthoek, omringd door kleinere rechthoeken die de externe entiteiten voorstellen. Externe entiteiten zijn mensen, organisaties, systemen en andere dingen die buiten het systeem staan, maar ofwel informatie aan het systeem toevoegen of er informatie uithalen. * Use case model: elke use case toont een script: een stap voor stap beschrijving van hoe een gebruiker ( = uitvoerder) gebruik kan maken van het systeem om een taak uit te voeren. * Interface descriptions: = grafische user interface: de schermen die de gebruikers gaan gebruiken. Dit toont dus hoe het systeem er voor de gebruiker zal uitzien.

The object model= data model Wordt voorgesteld door een klassediagram. Dit klassendiagram kan verschillende soorten klassen bevatten: entity classes, interface classes en control classes.

96

The requirements modelRequirement (vereiste) is een “service statement” of een “constraint( een beperking).- Service statement: een bedrijfsregel die altijd moet toegepast worden of een berekening die het systeem moet uitvoeren. - Constraint statement = een beperking op het gedrag van het systeem of een beperking op de ontwikkeling van het systeem.

Functional and nonfunctional requirements ( functionele en niet – functionele beperkingen)* Niet – functionele vereisten= beperkingen op de ontwikkeling en de implementatie van het systeem. - gebruikbaarheid: de gemakkelijkheid waarmee het systeem kan gebruikt worden- hergebruik: de gemakkelijkheid waarmee het systeem kan hergebruikt worden- betrouwbaarheid: voor gebruikers is het belangrijk om te weten of ze op het systeem kunnen vertrouwen.- prestatie: hoeveel tijd het systeem nodig heeft om er bepaalde info uit te halen, …- efficiëntie: kostenefficiënt? Maar: om te weten aan welke beperkingen het systeem moet voldoen, is het belangrijk dat je voldoende met je klant praat! Om aan alle info te komen die je nodig hebt, is het soms ook mogelijk dat je bepaalde stakeholders moet interviewen of observeren. Soms moet je als analist ook gaan onderhandelen: mensen vragen soms onmogelijke dingen. Als analist is het jouw taak om te zeggen welke dingen dan de belangrijkste zijn en best opgenomen worden in het systeem, en welke dingen best worden weggelaten uit het systeem. Soms kan het ook zijn dat je met conflicten zit tussen bepaalde vereisten: je kan dan dus niet aan alle vereisten voldoen en daarom is het belangrijk om te onderhandelen met je klant. Hierbij komt dat klanten hun vereisten soms kunnen wijzigen of dat bepaalde vereisten worden weggelaten. Het is belangrijk dat je met deze wijzigende behoeften van de klant rekening houdt. Daarom: “change management” nodig! Change management moet ervoor zorgen dat de veranderende behoeften worden opgenomen in het systeem.

The use case modelDit model houdt geen rekening met hoe het systeem precies in zen werk gaat. Waar we wel in geïnteresseerd zijn is hoe de gebruiker het met het systeem gaat werken. De gebruiker zal het systeem gebruiken door het bepaalde commando’s te geven en door het antwoord dat ze terugkrijgen van het systeem. Use cases beschrijven de interactie tussen het systeem en de gebruiker in termen van de acties die gebruiker uitvoert en het antwoord dat het systeem hierop geeft.Het use case model toont welke functies het systeem zou moeten bieden en het helpt om:- duidelijk te maken wat de gebruikers willen van het systeem- het is een startpunt voor het zoeken van objecten en klassen- het is een startpunt voor het zoeken van het gedrag van objecten en eventuele relaties tussen klassen. * Use case = een gebeurtenis die kan plaatsvinden

97

* Actor = de rol die iemand gaat spelenDaarom kan een actor nooit een naam zijn! Bv: actor = student en niet Dirk Peeters want dezelfde persoon kan verschillende rollen spelen. Een use case diagram is een visuele representatie van actoren en use cases samen met eventuele andere specificaties en definities. * Flow of events (stroom van gebeurtenissen) - main flow of events = als alles goed werkt, hoe gaat het systeem dan werken?= Sunny day scenario- exceptional flow = wat er gebeurt als er iets misloopt: wat kan er allemaal mislopen en hoe gaat het systeem reageren?

Use case diagramsSymbolen: Rechthoek = het systeem zelfOvaal = de use case zelfPoppetje = de actor. De rol van de actor schrijf je onder het poppetjeEen lijn = een communicatielijn

98

Voorbeeld van een use case diagram

*Primaire actoren = de gebruikers van het systeem*Secundaire actoren = mensen (rollen) die alleen maar bestaan om ervoor te zorgen dat de primaire actoren het systeem kunnen gebruiken. bv: personeel voor technische ondersteuning *Ontwikkeling van een use case diagram1 Identificeer alle actoren die het systeem zullen gebruiken2 Interview deze actoren zodat je weet wat hun functie is en zodat je weet wat ze moeten presteren3 Identificeer scenario’s4 Identificeer kleine stapjes in de verschillende scenario’s. Splits deze in verschillende use cases zodat ze gemakkelijk kunnen gebruikt worden in andere scenario’s.£5 Identificeer relaties tussen de use cases.

99

Descriptionsteps = Sunny day scenario: volledige beschrijving van wat er precies allemaal wordt uitgevoerd. Links schrijf je welke acties de actoren uitoefenen en rechts schrijf je hoe het systeem hierop gaat reageren.

Use cases organiseren*Packages = een mapje waarin je al je use cases gaat opnemen

*Generalisaties = Je hebt een actor op de use case die algemene kenmerken vastlegt, maar de details ga je in onderliggende niveaus vastleggen.

100

Bv: Beide klanten hebben een naam en klantID, maar het systeem werkt anders voor klanten die telefonisch bestellen of klanten die moeten worden bezocht.*Include : om aan te tonen dat een use case bepaalde componenten van een andere use case bevat.

bv: Een klant kan een order nakijken of een nieuwe order plaatsen, maar in beide gevallen moet hij zich valideren. *Extend: voor uitzonderlijke scenario’s: wordt dus niet altijd uitgevoerd, enkel in speciale gevallen.

OpmerkingActoren gaan altijd communiceren met use cases! Nooit tekenen dat actor met actor communiceert want actoren kunnen onderling niet communiceren!

Activity diagram = Op welke chronologische volgorde de use cases worden doorlopen.Toont de transacties tussen acties. Een gekleurd rondje kenmerkt het begin van een activiteit het einde van een activiteit wordt getoond door een cirkeltje met een stip in. Een ruit geeft een beslissing weer die men kan maken. Op basis van activity diagrammen kan men testscenario’s ontwikkelen.

101

Symbolen:

Voorbeeld van een activity diagram:

102

Om testscenario’s te vinden moet je al de paden die we kunnen ontdekken een nummer geven. Eerst doen we dit altijd in koppels van 2 nummers. Als we dan al die deelpaden hebben gaan we die combineren. Zo bekom je allemaal paden van beginpunt tot eindpunt.

103

Objecten en klassen

Klassen- en objectdiagrammen zijn een meer statische weergave van het systeem + een klein beetje dynamiek: het gedrag van de objecten zit hier mee in verwerkt. In klassendiagrammen worden associaties weergegeven: een associatie = hoeveel elementen van de 1ne klasse verbonden zijn met andere klasse + specifieke kenmerken van deze relatie.

Een klasse = een blauwdruk die de kenmerken van alle elementen die ze bevat beschrijft. Bij UML worden niet alleen de kenmerken beschreven, maar ook het gedrag van de objecten. Dit is het grote verschil met ERD: hier beschrijven de entiteiten alleen de kenmerken.

David Taylor Donut Diagram

Klasse verwijst altijd naar bedrijfsobjecten = objecten waarmee de gebruiker werkt in de “echte wereld”. Deze objecten kunnen een lange levensduur hebben, maar het object kan veranderen doorheen de tijd. Bv: student: verandert doorheen het systeem. In het 1ste jaar schrijft hij zich in voor bepaalde opleidingsonderdelen en op een later tijdstip behaalt hij zijn diploma en werkt hij misschien op lessius. Student werknemer

De waarde van het object is de waarde van de attributen en de associaties.

Het grootste probleem is het zoeken van de verschillende klassen. Om de klassen te vinden moet je 1ste alle zelfstandige naamwoorden aanduiden en daarna je afvragen of dit een goede klasse is. Kenmerken van een klasse: - als je verschillende kenmerken nodig hebt om het te beschrijven- als je meerdere elementen hebt. Maar: datum is geen klasse, dit is gewoon een kenmerk, hoewel er wel verschillende data zijn.

104

Opmerking: in een klassendiagram ga je niet aangeven op welke manier de gebruiker moet gaan werken met het systeem! Het toont alleen de attributen en de methodes die samengaan moet verschillende types van relaties die de klassen verbindt.

VoorstellingEen klasse wordt voorgesteld door een rechthoek. De naam van de klasse staan gecentreerd in de rechthoek. Een klasse kan ook een lijst van attributen/procedures bevatten.Procedures worden aangegeven door (). Tussen de () zetten we de parameters: ofwel gegevens verzamelen en in een klasse stoppen, ofwel gegevens uit een klasse halen en aan de buitenwereld tonen. Een berekend veld wordt aangetoond door er een / voor te plaatsen.

Zoals je hierboven kan zien, zijn er verschillende types velden:- string = tekstveld- boolean = veld dat 2 data kan bevatten bv: juist/fout- numeriek = getalEen objectdiagram wordt weergegeven door: naam van het object : naam van de klasseIn een objectdiagram worden geen procedures opgenomen, wel de specifieke gegevens voor elk kenmerk.

105

bv:

*Associatie: beschrijft de verbanden tussen elementen uit 2 verschillende klassen of beschrijft het verband tussen 2 elementen van dezelfde klasse. Een associatie heeft altijd een naam en een richting. Een associatie werkt altijd in 2 richtingen en je moet dus via een pijl aangeven in welke richting je de naam moet lezen. Er bestaan verschillende soorten associaties:

106

OpmerkingJe mag nooit indirecte associaties tekenen! Het onderstaande voorbeeld maakt dit duidelijk: in het onderstaande voorbeeld weten we wie welk huurcontract heeft afgesloten en weten we ook welke betaling bij welk contract hoort. Hierdoor weten we ook welke betaling bij welke klant hoort en is het dus NIET nodig om een associatie te maken tussen “customer” en “payment”.

X or contraintAan de hand van een voorbeeld wordt dit uitgelegd. In het onderstaande voorbeeld kan zowel een bedrijf als een persoon een bankrekening hebben. Vanuit “account” moeten we Xor contraint gebruiken om aan te tonen dat een rekening ofwel enkel aan een bedrijf kan behoren ofwel enkel aan een persoon kan behoren, nooit aan zowel een persoon als een bedrijf. Wat wel kan is dat een rekening aan meerdere personen/bedrijven behoort.

107

Generalisatie= een klasse is een verdere verfijning van een andere klasse. Bv: zoogdier is een dier, maar niet elk dier is een zoogdier. Zoogdier is dus een verfijning van de klasse dier.De hoofdklasse zetten we bovenaan, de subklasse zetten we eronder en we verwijzen naar de hoofdklasse via een pijl. De subklasse erft automatisch alle attributen over van de hoofdklasse en ook alle associatie van de hoofdklasse. In onderstaand voorbeeld hebben klant en werknemer verschillende attributen, maar ze hebben allebei de attributen die bij persoon horen.

Polymoriphsm = je kan en bepaald voorwerp op verschillende manieren voorstellen.Bijvoorbeeld: een orkest. In onderstaand voorbeeld wordt bij “muzikant” een heel eenvoudige procedure gecreëerd, zoals bijvoorbeeld: brengt geluid voort. Er worden dan verdere klassen gecreëerd. Hier moet je de detailuitwerking opnemen. Er is dus 2 keer een definitie van het gedrag “play”: bij de muzikant en bij elke verdere subklasse.

108

*Abstracte klasse: zijn handig om de structuur duidelijk te maken, maar wordt in de databank zelf niet gecreëerd. Abstracte klassen moeten we altijd aanduiden door er {abstract} achter te schrijven.*Samenstelling en aggregatie:- Samenstelling: de samenhang van de verschillende objecten wordt als 1 geheel beschouwd. Als je in onderstaand voorbeeld de fiets delete, dan verwijder je automatisch ook het wiel en de frame.- Aggregatie: alle onderdelen bestaan afzonderlijk, maar gevoelsmatig is dit toch 1 geheel en we beschouwen dit geheel ook als een apart ding. Als je de fiets verwijdert, blijven het wiel en de frame wel bestaan.

*Associatieklasse: wordt gebruikt bij veel op veel relaties. Een associatieklasse bevat hetzelfde aantal elementen als dat je terugvindt bij de klassen waartussen de veel op veel relatie bestaat.

109

voorbeeld van een associatieklasse:

Jacobson’s three types classification of objectsEr zijn dus verschillende typen objecten. Zo zijn er: - entity objects = dingen uit de wereld van de gebruiker- interface objects - control objects: dragen coplexe methodes waarvan het niet duidelijk is tot welke klasse ze behoren.

Het opbouwen van klassen-en objectdiagrammen* Zoek de klassenEen klasse is het belangrijkste onderdeel van een klassendiagram. Het is daarom belangrijk dat je de juiste klassen weet te vinden. Je doet dit door het probleem dat de gebruiker je voorlegt te bestuderen en er de zelfstandige naamwoorden in aan te duiden. Dit zijn meestal goede kanshebbers voor een klasse. Je moet echter wel opletten dat je alleen de relevante klassen opneemt!* Zoek associatiesAls je weinig klassen hebt, kan je associaties opstellen door middel van een matrix. Je kan ook associaties bekomen door vragen te stellen, bijvoorbeeld:- wat doet een student met een opleiding? een student schrijft in voor een opleiding- wat doet een klant met een product? een klant koopt een product. Zoals we reeds besproken hebben zijn er verschillende relaties. Een veel op veel relatie kan je tekenen door middel van een associatieklasse, maar ook door middel van twee 1 op veel relaties( zoals bij ERD).

VOOR OEFENINGEN OP UML EN KLASSENDIAGRAMMEN: ZIE CURSUS!

110

Hoofdstuk 9: Building an information architecture

[p. 467-500]

Normalisatie

Normalisatie is een proces om data te structureren, om zo duplicatie en

inconsistenties te minimaliseren. Het gaat meestal over 1 tabel die in twee

of meer tabellen wordt verdeeld en om relaties te creëren.

Normalisatie is een formeel proces dat verzekert dat elk onderdeel is

verbonden aan de klasse van objecten dat het werkelijk beschrijft.

Het is een techniek om data te structureren om zo data redundancy (=

dupliceren van data, = overbodigheden) en inconsistenties te

minimaliseren.

Het is een techniek om complexe databanken efficiënter te maken door

alle overbodigheden eruit te halen.

Normalisatie zal een tabel opsplitsen in 1 of meer tabellen en:

Elimineert alle herhalende groepen uit een lijst gegevens

Elimineert alle overbodige gegevens

Problemen die veroorzaakt worden door ‘redundancy’:

1. Storage inefficiencies: Het zorgt voor verspilde opslagruimte

2. Processing inefficiencies: Constante updates zullen vereist zijn

3. Errors: om dat er constante updates nodig zijn, zullen er

onwaarschijnlijk inconsistenties optreden;

Normalisatie is geen mechanisch proces. Je moet voornamelijk je gezond

verstand gebruiken. Elke entiteit of object zou 1 feit moeten opnemen.

Problemen zullen opduiken wanneer onafhankelijke gegevens samen

worden opgeslagen.

111

Normalisatie kan in het begin zeer tijdrovend en overbodig lijken maar kan

in veel gevallen rampen vermijden. Vele gebruikers denken dat ze snel

een database in elkaar kunnen steken zonder een tijdrovende analyse

vooraf. Een slechte structuur verhoogt echter het gevaar op invoerfouten

of kan er zelfs voor zorgen dat bepaalde informatie niet uit het systeem

kan worden gehaald.

Een klein voorbeeld geeft de gevaren van zo’n niet gestructureerde

gegevensopslag weer.

Een winkel geeft aan zijn klanten een klantenkaart waarop de naam en het

adres van de klant wordt vermeld, alsook de aankopen die werden

verricht. Per aankoop worden de datum en het aankoopbedrag vermeld.

Op het einde van het jaar krijgen de klanten een kortingbon ter waarde

van 7% van het totale aankoopbedrag van dat jaar. De winkelier beslist

om de gegevens elektronisch in een Excel spreadsheet bij te houden. Hij

kiest hiervoor één grote tabel aan te leggen met kolommen voor de naam,

adres, datum aankoop en aankoopbedrag. Per klant en per aankoopdatum

wordt een rij gecreëerd. Als een klant dus op vijf verschillende dagen iets

bij de winkelier koopt, dan heeft die klant vijf verschillende rijen in het

werkboek gekregen. De winkelier kan met volgende problemen worden

geconfronteerd:

o Een klant verhuist. Hierdoor moet de winkelier op verschillende

rijen in de spreadsheet dezelfde wijziging doorvoeren. Vergeet hij

een lijn aan te passen, dan is het achteraf (zeker voor een andere

gebruiker maar ook voor de winkelier) moeilijk of niet te achterhalen

wat het juiste adres is. Elke keer een klant een aankoop verricht,

moet de winkelier opnieuw alle adresgegevens invoeren. Typfouten

zijn vlug gemaakt. Hierdoor kan een klant bijvoorbeeld op de ene lijn

huisnummer 16 hebben en enkele regels verderop huisnummer 17.

112

o Op het einde van het jaar berekent de winkelier het bedrag voor

de kortingbons per klant. Vermits de aankoopgegevens het volgende

jaar niet meer nodig zijn, maakt hij de volledige lijst leeg, maar

hierdoor verliest hij alle adresgegevens. Hij zou natuurlijk ook alle

lijnen behalve één lijn per klant kunnen wegvegen en daarvan alleen

de adresgegevens overhouden. Maar bij het invoeren van

aankoopgegevens moet de winkelier dan steeds eerst nagaan of er

nog zo’n adreslijn zonder aankoopgegevens in de lijst voorkomt.

o Indien de winkelier de spreadsheets per jaar archiveert en telkens

met een lege spreadsheet start, dan is het niet eenvoudig om na te

gaan welke klanten er eventueel niet meer terugkomen. Had de

winkelier het normalisatie proces uitgevoerd in plaats van snel een

soort database in Excel op te bouwen, zou hij niet met al deze

problemen geconfronteerd worden. Het normalisatieproces zal

ervoor zorgen dat we één globale databasestructuur krijgen met een

set gerelateerde tabellen (= entiteiten) waarin de velden (=

attributen) uitsluitend afhankelijk zijn van de sleutel.

Hoe weet je wat er moet worden genormaliseerd ? Hiervoor moet je alle

(of toch alle belangrijke rapporten) van het huidige systeem verzamelen.

Gaat het om een nieuw systeem, stel dan de layout op van de nieuwe

rapporten. Gebruik je nog de klassieke methoden, dan weet je uit het DFD

welke informatie doorheen het informatiesysteem (het manuele of reeds

geautomatiseerde systeem) vloeit. Hieruit kun je afleiden welke rapporten

er precies worden gebruikt, of welke rapporten het systeem zou moeten

kunnen produceren. Ook als je de objectgeoriënteerde methoden gebruikt,

moet je nagaan welke rapporten er moeten worden geproduceerd. Per

rapport stel je dan eerst een niet genormaliseerde tabel op die je dan

stapsgewijze normaliseert. Het normaliseren is een formeel proces dat

wordt uitgevoerd op abstracte data. Maar om het normalisatieproces beter

te kunnen uitleggen, zullen we eerst de verschillende stappen van het

113

normalisatieproces uitvoeren met behulp van voorbeeldgegevens, om

nadien de normalisatie zelf uit te voeren op hetzelfde voorbeeld.

Vooraleer we met het normalizeren starten, is het aan te raden om eerst

een ERD te tekenen om de situatie goed in kaart te brengen. Dit helpt

zeker bij het bepalen van de herhalende groepen tijdens het

normalizeren . Het ERD kan ook worden gebruikt om op het einde van het

proces te toetsen of de genormalizeerde set tabellen correct zijn. Een ERD

komt quasi nooit exact overeen met de genormalizeerde set tabellen,

maar kan anderzijds niet fundamenteel ervan afwijken.

Vanuit het rapport stellen we de 0-de normaalvorm op. Deze bevat alle

ruwe gegevens van het rapport. Berekende waarden zoals het totaal

bedrag en de korting worden niet in de 0-de normaalvorm opgenomen.

Telkens de waarden nodig zijn, laten we het systeem deze waarden

berekenen op basis van de laatste up-to-date collectie gegevens. We

noemen deze 0-de normaalvorm soms ook wel een flat table.

In deze 0-de normaalvorm moeten we de sleutel aanduiden. De sleutel

(primary key, identifier) is een veld of een combinatie van velden die elke

rij op unieke wijze identificeert. Namen van personen zijn dus zeker geen

sleutel. De sleutel moet ook zo eenvoudig mogelijk zijn. Vermijd dus ook

lange tekstwaarden. En als je een uitgebreide reeks velden moet

aanduiden als sleutel, dan is dit zeker ook geen goede keuze.

Normalisatieproces

Uitgelegd aan de hand van een voorbeeld nl. de klantenkaart

114

Normalisatie is een techniek om complexe informatiesystemen meer

efficiënt te maken, door alle ongewenste overbodigheden te

verwijderen.

Het normalisatieproces wordt echter uitgevoerd op een abstracte set

gegevens.

Er zijn 4 stappen die doorlopen moeten worden:

0NF 1NF 2NF 3NF

De eerste belangrijke stap is het aanduiden van de ruwe gegevens op

het rapport (berekende waarden worden niet opgenomen). In dit

voorbeeld zijn dit: naam klant, voornaam klant, adres, postcode,

gemeente, telefoon, aankoopdatum, productcode, omschrijving, bedrag.

Het totaal en de korting is informatie die wordt berekend aan de hand van

de productprijzen en wordt daarom niet opgenomen in de 0-de

normaalvorm. Ze worden steeds berekend op het moment dat deze

informatie nodig is. Zo zijn we zeker dat het totaal en de korting steeds

gebaseerd op de meest recente gegevens in het systeem.

Enkele definities:

Primary key: Dit is een attribuut (kolom of veld) of een combinatie

van attributen, die gebruikt kunnen worden om een entiteit te

identificeren.

Foreign key: Dit is een kolom of een combinatie van kolommen die

verwijzen naar een primaire sleutel in een (andere) tabel.

115

STAP 1: 0NF = FLAT TABLE

Verzamel alle data

Verwijder alle gegevens die berekeningen bevatten

Kies een primaire sleutel (deze onderstrepen)

Duid de herhalende groepen aan (met accolades)

Eventuele herhalende groepen gegevens zet je tussen accolades. Om de

herhalende groep gegevens op te sporen, moet je denken in termen van

entiteiten en attributen. De 0-de normaalvorm Purchases bevat attributen

van de entiteiten klant (CustomerID, LastName, FirstName, Address,

PostalCode, City, Phone) en van de echte aankoopgegevens (Date, Article,

Description, Amount). Bij één element van de entiteit CUSTOMER horen

meerdere elementen van de PURCHASE. Als we dus één element in de

entiteitklasse CUSTOMER invullen, dan moeten we daarna meerdere

elementen in de klasse PURCHASE invullen, m.a.w. we moeten meerdere

keren waarden geven aan de groep attributen Date, Article, Description,

Amount. Deze groep is dan ook de herhalende groep gegevens in de 0-de

normaalvorm.

In dit voorbeeld zie je ook duidelijk dat binnen een herhalende groep

gegevens nogmaals een herhalende groep gegevens kan zitten. Immers

per dag dat een klant iets aankoopt, kan hij/zij meerdere artikels kopen.

Duidt ook meteen de sleutel aan in deze 0-de normaalvorm. Vermits we

alles bekijken vanuit de klantengegevens, is de klantencode dan ook de

sleutel. Sleutels duidt je aan door de naam van het attribuut te

onderlijnen.

116

STAP 2: 1NF

Als de 0NF een herhalende groep bevat:

- Herschrijf de 0NF maar verwijder de gegevens van de

herhalende groep

- Creëer een tweede data set met de herhalende gegevens

van 0NF

- Gebruik opnieuw de primaire sleutel van de 0NF in de

nieuwe set

Bepaal een nieuwe primaire sleutel in beide tabellen

- De primaire sleutel in de eerste groep zal dezelfde zijn als in

0NF

- De nieuwe tabel gegevens heeft gewoonlijk een

samengestelde sleutel, bestaande uit de primary key van

de 0-de normaalvorm gecombineerd met één of meerdere

andere velden.

Dus:

• 0de normaalvorm:

Purchases = (CustomerID, LastName, FirstName, Address, PostalCode,

City, Phone, {Date, {Article, Description, Amount}})

• 1ste normaalvorm:

(tussenstap)

Customer = (CustomerID, LastName, FirstName, Address,

PostalCode, City, Phone)

Purchases = (CustomerID, Date, {Article, Description, Amount})

(eindresultaat)

Customer = (CustomerID, LastName, FirstName, Address, PostalCode,

City, Phone)

Purchases = (CustomerID, Date)

117

PurchasesDetails = (CustomerID, Date, Article, Description, Amount)

(Elke herhalende groep gegevens moet worden afgesplitst en

ondergebracht worden in een nieuwe tabel. De nieuwe tabellen bevatten

naast de gegevens van de herhalende groep ook de primary key van de 0-

de normaalvorm. Dit veld vormt de relatie tussen beide tabellen.)

Stap 3: 2NF

Zoek naar niet-sleutelvelden (= niet onderstreepte velden) die maar

voor een deel afhankelijk zijn van de primaire sleutel. In elke set

waar dus een samengestelde sleutel voorkomt, moet dus worden

onderzocht of andere niet-sleutelvelden afhankelijk zijn van een deel

van de samengestelde sleutel.

Indien dit zo is, moet je een nieuwe dataset voor deze velden

creëren samen met het veld waarvan zij afhankelijk zijn en verwijder

hen van de originele set.

Bepaal voor elke nieuwe set een nieuwe sleutel.

Voorbeeld:

Customer = (CustomerID, LastName, Fistname, Adress, Postcode City,

Phone)

Purchases = (CustomerID, Date)

PurchaseDetails = (CustomerID, Date, Article)

Articles = ( Article, Desciption, Amount)

(in dit voorbeeld bevat de table Customer een enkelvoudige sleutel, dus

die set is al in de tweede normaalvorm. De tabel Purchases heeft een

samengestelde sleutel, maar geen niet-sleutelvelden = allemaal

onderstreept). In de tabel purchasesdetails zijn de niet-sleutelvelden,

Description en Amount, afhankelijk van een deel van de sleutel Article.

Deze velden splitsen we dus af in een afzonderlijke tabel Articles.

118

Stap 4: 3NF

Voor elke dataset: check of niet-sleutelvelden afhankelijk zijn van

andere niet-sleutelvelden

Als dit wel het geval is: maak een nieuwe set aan met deze velden.

Verwijder alle velden van de originele set, behalve het veld waarvan

ze afhankelijk zijn.

Bepaal de primary keys in de nieuwe set.

Elk attribuut moet direct afhankelijk zijn van de sleutel!

Voorbeeld:

Customer = (CustomerID, LastName, Fistname, Adress, Postcode

City, Phone)

Purchases = (CustomerID, Date)

PurchaseDetails = (CustomerID, Date, Article)

Articles = (Article, Desciption, Amount)

Cities = (Postcode, City)

In dit voorbeeld is er in de tweede normaalvorm enkel afhankelijkheid

tussen de niet-sleutelvelden PostalCode en City. Dus deze twee velden

worden in een afzonderlijke tabel ondergebracht.

119

De elementen van het Analysis Model

State Transition Diagram

Tijdafhankelijk gedrag modelleren

Een aaneenschakeling van processing data

= belangrijk voor online en real-time systemen

120

Data Dictionaries

Om een consistente databank te waarborgen, zullen organisaties gebruik

maken van een data dictionary. Dit wordt gebruikt als een soort

‘catologus’ van alle gegevens, die alle namen, structuren en informatie

over het gebruik van deze gegevens bevat.

Een data dictionary zou deze elementen moeten bevatten:

Definities van de verschillende elementen

Tabeldefinities

Een databankschema (een schematische representatie van de hele

tabel.

Bevat meerbepaald: naam, alias, waar-gebruikt-? en hoe-gebruikt-?,

inhoudelijke beschrijving, bijkomende informatie

Welke symbolen worden er gebruikt?

121

Verschil tussen websites en intranet

Website = een publiek toegankelijke site, beschikbaar op het World Wide

Web.

122

Intranet = een combinatie van interne websites, e-mail en ‘hosted

applications’.

In termen van technologie, werken ze beiden via hetzelfde platvorm

(webbrowser).

Intranet maakt geen intensief gebruik van grafische toepassingen.

De inhoud is eerder breed dan diepgaand en ze bestaan in

verschillende formaten waarvan velen niet expliciet zijn geschreven

voor op het web te publiceren.

Websites worden vaak onderhouden door kleine teams specialisten

die verantwoordelijk zijn voor de inhoud en het management van de

website.

WireframeDit is een vorm van ontwerp dat gebruikt wordt door webdesigners om

een webpagina voor te stellen, alvorens web editing tools worden gebruikt

om de webpagina te creëren. Het is een schematische manier om de lay-

out van een individuele webpagina voor te stellen. Ze duidt de belangrijke

elementen en relaties aan en hun relatieve belang.

Navigation systemsWanneer je een navigatiesysteem wil ontwerpen zal een bepaalde

structuur moeten ontworpen worden. Er zijn twee soorten structuren:

Small en diep (narrow and deep): Weinig links op de pagina’s, maar

veel clicks nodig om neerwaarts door de structuur te navigeren naar

de benodigde informatie. Dit werkt het beste bij websites of

intranets die gespecialiseerd zijn in bepaalde gebieden.

Breed en oppervlakkig (broad and shallow): Veel links op de

pagina’s, maar weiniger clicks nodig om naar de benodigde

informatie te navigeren. Dit zal het beste werken bij websites of

intranets die een breed aanbod aan informatie verschaffen die in

123

groepen kunnen ingedeeld worden. Intranets kunnen het beste

werken onder deze structuur.

Seach versus browseIntranets groeien gewoonlijk heel snel en het volume van de inhoud neemt

toe, waardoor informatie opzoeken moeilijk wordt. Hierdoor is een ‘High

end search engine’ een absolute noodzaak. Deze geeft een gedetailleerde

indexering en geavanceerde zoekfuncties.

Taxonomy, thesauri and controlled vocabularies

Controlled vocabulary = een lijst van gedefinieerde termen in de vorm van

een ‘synonym ring’. Een synonym ring is een set van woorden die als

equivalent zijn gedefinieerd.

Dus als je iets opzoekt en je gebruikt een woord uit deze synonym

ring, dan zal je dezelfde uitkomst bekomen.

Vb. teacher, lecturer, teaching staff, module leader

124

Ook wanneer een pagina de naam teacher heeft, noemen we deze

de preferred term. Wanneer iemand dan zoekt op bv. lecturer, is dat

woord de variant term.

Taxonomy = In de informatica ontstaat meer en meer de behoefte te komen tot een

gemeenschappelijke terminologie in systemen en databases, onder andere ten behoeve

van de integratie van gegevens uit verschillende systemen en ten behoeve van de

eenduidige uitwisseling van productgegevens, zoals in e-business systemen en

kennisgestuurd ontwerpen. Deze structuur heeft onder andere als groot voordeel dat

eigenschappen van supertypen geërfd worden door de subtypen.

Thesaurus = een meer ontwikkelde en meer complexe controlled vocabulary, die relaties

toont tussen termen zoals de hiërarchische relaties, hun gelijkaardigheid en hun

verbindingen met elkaar.

Usibility = de mogelijkheid van systemen om tegemoet te komen aan de eisen van de

gebruikers.

Security designHet security design proces zal zich concentreren op het correct ten uitvoer brengen van

de genomen veiligheidsmaatregelen.

Wat is het verschil tussen richtlijnen, een standaard en een beleid?

Een beleid is typisch een document dat de precieze vereisten of regels beschrijft die

moeten worden nageleefd.

Een standaard is een collectie van systeem-specifieke of procedure-specifieke vereisten

die door iedereen moeten worden nageleefd.

Een richtlijn is een collectie van systeem-specifieke of procedure-specifieke suggesties

voor beste gebruik ervan.

Acceptable use policies

Het doel van een acceptable use policy is om een globaal beleid samen te vatten voor de

gebruikers, waarin de verantwoordelijkheden met betrekking tot de informatiebeveiliging

in de organisatie van de gebruiker worden uiteengezet.

125