Auteur: Stefan de Lange
Opdrachtgever: Rijksuniversiteit Groningen
LogicaCMG Nederland
Datum: 12 mei 2006
Plaats: Groningen
Auteur: Stefan de Lange
Opdrachtgever: Rijksuniversiteit Groningen
Faculteit Bedrijfskunde
LogicaCMG Noord-Nederland
Opleiding: Technische Bedrijfswetenschappen Informatie technologie
Begeleiders: Dr. H. Balsters
Prof. Dr. G.B. Huitema Referenten: Drs. B.F. Jonk
G.J. Pottjewijd
Datum: 12 mei 2006
Plaats: Groningen
VOORWOORD
Voor u ligt het verslag van mijn afstudeeropdracht behorende bij de studie Technische Bedrijfswetenschappen aan de Rijksuniversiteit Groningen. Deze afstudeeropdracht is uitgevoerd bij LogicaCMG Noord-Nederland gedurende de periode van een half jaar.
Dit verslag is in de eerste plaats geschreven voor de universitair begeleiders en de belanghebbende van LogicaCMG, daarnaast kan het verslag van waarde zijn voor een ieder die geïnteresseerd is in informatieanalyse.
Vele personen hebben bijgedragen aan de totstandkoming van dit afstudeerverslag.
Mijn eerste dank gaat uit naar dr. H. Balsters voor zijn voortreffelijke begeleiding vanuit de Faculteit Bedrijfskunde. Daarnaast wil ik ook prof. dr. G.B. Huitema hartelijk bedanken voor zijn begeleiding en bijdrage aan de kwaliteit van deze scriptie.
Mijn dank gaat ook uit naar LogicaCMG Noord-Nederland voor de gelegenheid die mij gegeven is om het onderzoek te doen binnen haar organisatie. Van deze organisatie wil ik in het bijzonder Geert Jan Pottjewijd, Bart Jonk en Erik Lammers bedanken voor hun prettige en intensieve begeleiding gedurende het onderzoek.
Stefan de Lange
Groningen, mei 2006
SAMENVATTING
Deze scriptie gaat over de modellering van informatiesystemen en de instrumenten die de informatieanalist daarbij kan gebruiken. Bij de ontwikkeling van een
informatiesysteem is het de taak van de informatieanalist om de functionaliteit van het systeem af te stemmen op de eisen en wensen van de opdrachtgever. Bij de informatieanalisten van LogicaCMG speelde de vraag hoe modellen kunnen bijdragen aan deze afstemming en welke instrumenten daarbij ondersteuning kunnen bieden. In deze scriptie wordt aangetoond dat modellen van groot belang zijn bij het communiceren en toetsen van het inzicht in het probleemgebied tussen de betrokkenen van het systeemontwikkelingsproject. Het blijkt dat geschikte instrumenten de informatiebehoeftebepaling kunnen verbeteren en dat dit resulteert in een informatiesysteem dat beter aansluit bij de eisen en wensen van de opdrachtgever. Het onderzoek gaat dan ook uit van de volgende doelstelling:
Het selecteren van modelleringsmethoden, -technieken en -tools die de informatieanalist zodanig helpen te voorzien in zijn of haar
modelleringsbehoefte dat de specificatie van het informatiesysteem voldoet aan de eisen en wensen van de opdrachtgever.
Om tot een selectie van de instrumenten te komen is eerst inzicht nodig in de modelleringsbehoefte van de informatieanalist. Door middel van literatuur, interviews en een vragenlijst is inzicht verkregen in de huidige en toekomstige modelleringsbehoefte. Met behulp van dit inzicht is vervolgens getoetst in hoeverre de huidige instrumenten aan deze modelleringsbehoefte helpen te voldoen. Dit heeft geleid tot de volgende aanbevelingen:
1. Om de specificatie beter te kunnen communiceren naar niet-technische domeinexperts (bijvoorbeeld een gebruiker of een opdrachtgever) zou deze op een conceptueel niveau moeten worden beschreven. Een conceptueel model is namelijk specifiek gericht op het overbrengen van het inzicht in de probleemsituatie.
2. Om onduidelijkheden in de vorm van dubbelzinnigheden of inconsistenties in modellen te kunnen voorkomen, zouden de modellen op een formelere manier moeten worden vastgelegd. Informele, natuurlijke taal blijkt niet eenduidig te interpreteren en kan leiden tot misverstand.
3. Moderne tools kunnen bijdragen aan de kwaliteit en de productiviteit van de
informatieanalyse. Controle op de consistentie, beheer van de verschillende
versies en automatische transformatie van modellen zijn voorbeelden van
functies die van grote waarde kunnen zijn voor de informatieanalist. Huidige
hulpmiddelen zijn voornamelijk tekstverwerkers en tekenpakketten en deze
bieden weinig ondersteuning.
4. De technieken en tools zouden moeten voldoen aan een industriële standaard. Als modellen voldoen aan een standaard dan kunnen ze elkaar beter aanvullen en zijn ze beter te vergelijken. Bovendien ondersteunen tools voornamelijk standaard modelleringstechnieken waardoor de techniek een betere aansluiting zou vinden bij een tool.
Met het oog op deze aanbevelingen zijn er beoordelingscriteria geformuleerd waaraan de instrumenten zouden moeten voldoen. Deze beoordelingscriteria zijn toegepast op een selectie van methoden, technieken en tools. Uit deze beoordeling is gebleken dat de methoden TOGAF (voor een nadruk op de
informatiearchitectuur), ARIS (voor een nadruk op bedrijfsprocessen) en RUP (voor een nadruk op softwareontwikkeling) het beste modelleringsraamwerk voorschrijven. Technieken als BPMN (voor de bedrijfsprocessen) en ORM (voor het datamodel) stellen de analist in staat om goede conceptuele modellen te maken.
UML is een modelleringstechniek die momenteel dé standaard
systeemmodelleringstaal is en zeer geschikt is voor de modellering van het
technische ontwerp. Deze technieken hebben alle drie ook een voldoende formele ondergrond om ondubbelzinnige en heldere modellen te kunnen maken. Door gebruik te maken van tools als IBM Rational Rose Software Modeler samen met RequisitePro (voor de nadruk op softwareontwikkeling), IDS Scheer ARIS Business Architect (voor de nadruk op bedrijfsprocessen) of Telelogic System Architect (voor de nadruk op de informatiearchitectuur) is een goed beheer van de modellen mogelijk en wordt de analist ondersteund bij het toepassen van formele en
standaard modelleringstechnieken als BPMN en UML.
SUMMARY
This thesis deals with requirement modeling and the instruments that support this activity. During the development of an information system it is the analyst’s task to align the information provision (i.e. the information system) with the information requirement. The analysts of LogicaCMG asked themselves how models can contribute to this alignment and which instruments can support this activity. This thesis shows that the analyst’s models play an important role in the process of requirement determination. The models are of great value in the process of creating mutual understanding of the problem domain for all participating members of the project team. This thesis also shows that the use of the right instruments can improve the process of requirement determination. The use of these instruments will result in an information system that likely will be better able to meet the user’s needs. The main objective of the research is:
To select modeling methods, techniques and tools that meet the analyst in his or her modeling needs in such a way that the models represent an information system that correctly meets the information requirements.
Before we could make a selection of instruments we had to gain better insights into the modeling needs of the analyst. With the use of literature, interviews and a questionnaire insight was gained in the present and future modeling needs. This insight was used to measure the extent in which the present instruments might be helpful to meet these needs. This resulted in four recommendations:
1. To improve the communication of the requirement specifications to non-technical domain experts the analyst should model the
specifications at a conceptual level. A conceptual model is specifically focused to gain better insights in the problem domain.
2. To prevent misunderstandings in the semantics of a model the analyst should use formalized modeling techniques. Formulating requirements in an informal, natural language leaves to much room for personal interpretations and can lead to misunderstandings.
3. Modern tools can contribute to the quality and to the productivity of the requirement specification process. Consistency checks, version
management and forward or reverse engineering are examples of useful tool functionalities. Present tools are mainly word processors and drawing tools.
4. The technique and tools should comply with industry standards. Models
that comply with a standard are better able to complement one another
and can easily be compared. Moreover, modeling tools are focused
usually based on one or more industry standards which make a better
match between the technique and the tool.
With the acknowledgement of these recommendations evaluation criteria for the instruments were formulated. These criteria have been applied to a selection of methods, techniques and tools. The outcome of the evaluation showed that the TOGAF (for an emphasis on architecture), ARIS (for an emphasis on business process) and RUP (for an emphasis on software
development) methods prescribe the best modeling framework. Techniques as
BPMN (for modeling business process) and ORM (for modeling data structure)
result in the best conceptual models. UML is considered to be the software
development language and is therefore the most suitable for modeling the
system design. All three techniques provide in an adequate formal foundation
to produce clear and unambiguous models. Modeling tools as IBM Rational
Rose Software Modeler in combination with IBM RequisitePro (for an
emphasis on software development), IDS Scheer ARIS Business Architect (for
an emphasis on business process management) and Telelogic System Architect
(for an emphasis on information architecture) enable an adequate model
management and support the analyst with the application of formal and
standard modeling techniques as BPMN and UML.
INHOUDSOPGAVE
1 Inleiding ...11
1.1 Inleiding...11
1.2 Achtergrond van het onderzoek ...11
1.3 Organisatie van LogicaCMG...12
1.4 Consultancy...12
1.5 Informatie- en communicatietechnologie...13
1.6 Systeemontwikkeling...14
1.7 Samenvatting...15
2 Onderzoeksopzet ...16
2.1 Inleiding...16
2.2 Inleiding tot de probleemstelling...16
2.3 Voorlopige probleemstelling...16
2.4 Onderzoeksvragen...17
2.5 Afbakening van het onderzoek ...18
2.6 Conceptueel onderzoeksmodel...18
2.7 Plan van aanpak ...19
2.8 Leeswijzer...21
2.9 Informatiebronnen...22
2.10 Samenvatting...22
3 Informatieplanning...23
3.1 Inleiding...23
3.2 Informatiesysteem...23
3.3 Informatieanalist ...24
3.4 Informatieanalyse...25
3.5 Informatieverzameling...27
3.6 Niveau van detail...27
3.7 Samenvatting...28
4 Specificatie van de analyse...29
4.1 Inleiding...29
4.2 Activiteiten ...29
4.2.1 Elicitatie...30
4.2.2 Specificatie...30
4.2.3 Validatie...31
4.3 Analyse en synthese...31
4.4 Formaliseren...32
4.5 Conceptualiseren...34
4.6 Inhoud van de specificatie...35
4.7 Samenvatting...36
5 Modellen...38
5.1 Inleiding...38
5.2 Doelstelling van het model...38
5.3 Abstractieniveau...39
5.4 Kwaliteit van het model...40
5.5 Modellen van de informatieanalist...40
5.5.1 Procesmodel...40
5.5.2 Datamodel...41
5.5.3 Besturingsmodel...41
5.6 Modellering van informatiesystemen...41
5.6.1 Functionele benadering ...41
5.6.2 Objectgeoriënteerde benadering...42
5.6.3 Bedrijfsprocesbenadering...43
5.7 Modelleringsraamwerk ...43
5.8 Samenvatting...44
6 Methoden, technieken en tools...45
6.1 Inleiding...45
6.2 Inleiding tot methoden ...45
6.3 Keuze van methoden...46
6.4 Overzicht van methoden...48
6.4.1 SA/SD...48
6.4.2 IE...48
6.4.3 RUP...48
6.4.4 DEMO...49
6.4.5 DSDM ...49
6.4.6 ARIS...49
6.4.7 TOGAF ...50
6.5 Inleiding tot technieken...50
6.6 Keuzen van technieken...51
6.7 Overzicht van technieken...51
6.7.1 Flowchart...51
6.7.2 DFD...52
6.7.3 BPMN ...53
6.7.4 ERD...54
6.7.5 ORM ...55
6.7.6 UML...56
6.8 Inleiding tot tools...58
6.9 Meerwaarde van modelleringstools...59
6.10 Keuze van tools ...60
6.11 Overzicht van tools ...62
6.11.1 IDS Scheer ARIS...62
6.11.2 Telelogic System Architect ...62
6.11.3 Telelogic DOORS/Analyst ...62
6.11.4 IBM Rational Software Modeler en Requisite...63
6.11.5 Borland CaliberRM en Together Architect...63
6.11.6 Microsoft Visio Enterprise Architect...63
6.12 Samenvatting...64
7 Praktische achtergrond...65
7.1 Inleiding...65
7.2 Vragenlijst...65
7.3 Huidige praktijksituatie...65
7.4 Gebruik van technieken en tools ...66
7.5 Trends ...67
7.5.1 Enterprise Architecture (EA)...67
7.5.2 Business Process Management (BPM)...67
7.5.3 Model Driven Architecture (MDA)...68
7.6 Samenvatting...69
8 Analyse van de modelleringsbehoefte...70
8.1 Inleiding...70
8.2 Modelleringsbehoefte...70
8.3 Knelpunten...71
8.4 Huidige tekortkomingen...72
8.5 Toekomstige tekortkomingen ...74
8.6 Definitieve probleemstelling...74
8.7 Samenvatting...75
9 Beoordeling van de instrumenten...76
9.1 Inleiding...76
9.2 Selectiecriteria voor de instrumenten ...76
9.2.1 Criteria voor de methode...76
9.2.2 Criteria voor de techniek...78
9.2.3 Criteria voor de tool...80
9.3 Toepassing van de criteria op de instrumenten...82
9.3.1 Beoordeling van de methoden ...82
9.3.2 Beoordeling van de technieken...84
9.3.3 Beoordeling van de tools...93
9.4 Samenvatting...97
10 Aanbevelingen...98
10.1 Inleiding...98
10.2 Conceptualiseren...98
10.3 Formaliseren...99
10.4 Gebruik van tools...100
10.5 Standaardiseren...100
10.6 Beperking ...101
10.7 Samenvatting...102
11 Conclusie ...103
Literatuurlijst...104 Bijlage I: Lijst met afkortingen
Bijlage II: Vragenlijst
"If I had eight hours to chop down a tree, I’d spend six sharpening my axe."
Abraham Lincoln
1809 - 1865
1 INLEIDING
1.1 Inleiding
Een bedrijfskundig onderzoek wordt vaak gekenmerkt door een
probleemoplossende aanpak. Hierbij gaat het onderzoek uit van een bepaald probleem in de huidige situatie. Het in deze scriptie beschreven onderzoek gaat ook uit van een probleemsituatie maar het begrip probleem moet in dit rapport ook ruimer worden geïnterpreteerd als een uitdaging of een kans tot verbetering van de situatie. In dit eerste hoofdstuk zal een inleiding tot het onderzoek worden
gegeven. Hierbij geeft paragraaf 1.2 inzicht in de achtergrond van de opdracht. In paragraaf 1.3 zal het bedrijf LogicaCMG en haar organisatie worden
geïntroduceerd. Paragraaf 1.4 zal vervolgens ingaan op de activiteiten van LogicaCMG die van belang zijn voor het onderzoek. De rol die ICT binnen een organisatie speelt en de manier waarop ICT in een informatiesysteem wordt toegepast zal in paragraaf 1.5 en 1.6 worden besproken. Het hoofdstuk zal in paragraaf 1.7 worden afgesloten met een samenvatting.
1.2 Achtergrond van het onderzoek
Informatie en communicatietechnologie (ICT) is tegenwoordig een onmisbaar element binnen organisaties. Binnen een organisatie wordt deze technologie voornamelijk ingezet voor het beheren van de verschillende informatiestromen.
Deze informatiestromen worden hierbij geregeld door een informatiesysteem.
Tijdens de ontwikkeling van een informatiesysteem heeft de informatieanalist een sleutelrol: deze moet de brug slaan tussen de organisatie en de technologie. De informatieanalist moet hierbij in staat zijn om het technische aanbod af te kunnen stemmen op de bedrijfskundige vraag van de organisatie. Het doel van de
informatieanalyse is het hoe en waarom van een ICT-project vast te stellen. Tijdens deze analyse maakt de analist een model van het probleem- en oplossingsgebied.
Dit model vormt een abstracte weergave van een (deel van) de organisatie en het informatiesysteem dat (dit deel van) de organisatie moet gaan ondersteunen. Een belangrijke doelstelling van het model is het begrijpelijk en inzichtelijk maken van het probleemgebied voor de betrokkenen van het ICT-project. Het is vooral van belang dat de opdrachtgever een goed inzicht heeft in het probleemgebied zodat het toekomstige informatiesysteem volledig voldoet aan zijn eisen en wensen. Om tot een geschikt model te komen kan de analist gebruik maken van vele
verschillende instrumenten. Tijdens de analysefase van een ontwikkelingsproject bleek dat er bij LogicaCMG regelmatig vragen worden gesteld over deze
instrumenten. Er bestaat een gevoel dat ‘er veel is’ maar er ontbreekt inzicht in het landschap van modelleringsmethoden, -technieken en –tools (i.e. gereedschappen).
Deze behoefte tot inzicht bestaat zowel extern, bij de klanten van LogicaCMG als
intern, bij de eigen informatieanalisten. De vraag wat goede modellen zijn en
welke instrumenten de analist het beste kunnen helpen om tot goede modellen te komen vormt de aanleiding tot dit onderzoek.
1.3 Organisatie van LogicaCMG
LogicaCMG is als dienstverlener wereldwijd actief op het gebied van ICT consultancy, systeemintegratie en outsourcing. LogicaCMG is verantwoordelijk voor vele backoffice applicaties die doorgaans onzichtbaar zijn voor de consument.
Maar het bedrijf is ook actief in meer spraakmakende opdrachten zoals de Huygens satelliet. Deze satelliet is op weg naar Titanus, de grootste maan van Saturnus, met vluchtsoftware die door LogicaCMG is ontwikkeld. Bij deze grote diversiteit aan activiteiten heeft LogicaCMG ook een bijpassende missie geformuleerd:
“Onze missie is toonaangevende bedrijven overal ter wereld te helpen met het bereiken van hun bedrijfsdoelstellingen door het innovatief inzetten van zowel informatie- en communicatietechnologie als oplossingen voor
bedrijfsprocessen.”
Deze missie voert LogicaCMG uit door klanten in diverse sectoren, zoals de telecommunicatiesector, het bank- en verzekeringswezen, de transportsector en overheden te ondersteunen met hun expertise in informatie- en
communicatietechnologie. De onderneming is in december 2002 ontstaan uit de fusie van het Britse Logica en het Nederlandse CMG, heeft circa 30.000
medewerkers in dienst en kantoren in 36 landen. LogicaCMG heeft haar hoofdkantoor in Europa en is genoteerd aan de beurzen van Londen en
Amsterdam. LogicaCMG Nederland is ingedeeld naar 7 divisies die ieder hun eigen marktsectoren bedienen. Het afstudeeronderzoek is uitgevoerd in Groningen bij de divisies Energie & Utilities en Telecom. In Groningen rekent LogicaCMG
voornamelijk de grote organisaties in Noord-Nederland tot haar klanten.
Voorbeelden zijn Gasunie, KPN, Essent en Univé verzekeringen.
1.4 Consultancy
Dit onderzoek is uitgevoerd in opdracht van een team van informatieanalisten. De informatieanalist wordt doorgaans gedetacheerd of als consultant bij een klant ingezet. De analist wordt hierbij door een klantorganisatie gecontracteerd voor het bijdragen aan een ICT-project. De achtergrond van een dergelijk project is vaak de behoefte om in te spelen op veranderingen als het invoeren van nieuwe producten, nieuwe technologieën, nieuwe processen, enzovoort. Een project is een geheel van activiteiten, dat uitgevoerd wordt door meerdere specialistische groepen in een tijdelijk samenwerkingsverband dat gericht is op een gespecificeerd resultaat. Dit resultaat dient doorgaans te worden bereikt binnen een begrensde tijd met begrensde middelen. Projecten worden bemand door mensen uit de
klantorganisatie en/of door externe specialisten (bijvoorbeeld van LogicaCMG)
voor de duur van (een deel van) het project. Externe specialisten (consultants) worden doorgaans ingezet wanneer het de klantorganisatie ontbreekt aan mensen en/of kennis om het project uit te kunnen voeren. Een ICT-dienstverlener kan zijn consultants op twee manieren deel laten uitmaken van een project: op basis van een inspanningsverplichting of op basis van een resultaatverplichting. Wanneer een specialist op basis van een inspanningsverplichting een klantorganisatie dient, dan wordt het ICT-project meestal uitgevoerd onder de regie van de interne IT afdeling. Deze IT afdeling maakt voor de uitvoering van het project gebruik van door de organisatie vastgestelde standaarden. Deze standaarden bepalen welke eisen er aan de verschillende producten worden gesteld en volgens welke
methoden deze producten dienen te worden ontwikkeld. De externe ICT-specialist die als consultant wordt ingezet om het projectteam te bemannen, wordt op basis van een contract ingehuurd. In dit contract wordt vastgelegd welke kennis, vaardigheden en tijd de consultant aan de klant ter beschikking stelt en welke vergoeding daar tegenover staat. De consultant gaat hiermee een
inspanningsverplichting met de klantorganisatie aan (detachering). De kenmerken van een inspanningsverplichte overeenkomst zijn:
•
De klant heeft de regie over het project;
•
De klant beoordeelt zelf de kwaliteit.
Als een specialist op basis van een resultaatverplichting wordt gecontracteerd dan wordt in dit contract onder andere vastgelegd welke producten worden
opgeleverd, op welke datum en tegen welke vergoeding dit gebeurt. Hiermee gaat de consultant een resultaatverplichting met de klantorganisatie aan. De kenmerken van een resultaatverplichte overeenkomst zijn:
•
De consultant heeft de regie over de opdracht;
•
De kwaliteit wordt bewaakt door het kwaliteitssysteem van de consultant.
De opdrachten tot informatieanalyse vinden doorgaans plaats op basis van een inspanningsverplichting hetgeen van groot belang zal blijken in het onderzoek.
1.5 Informatie- en communicatietechnologie
ICT vormt het middelpunt van de activiteiten van een ICT dienstverlener.
Tegenwoordig wordt iedere organisatie wel op één of andere manier ondersteund
door ICT. De rol die ICT binnen een organisatie speelt kan per organisatie enorm
verschillen. Vragen die deze rol duidelijk maken zijn: hoe wordt ICT ingezet
binnen de bedrijfsprocessen en hoe belangrijk is ICT voor het bereiken van de
organisatiedoelen? Van Hootegem et al. (2001) maken onderscheid tussen drie
niveaus van toegevoegde waarde die ICT aan de organisatie kan leveren: ICT kan
ingezet worden als facilitator, enabler of als driver. Daar waar ICT als facilitator
wordt gezien, richt de technologie zich voornamelijk op het ondersteunen van
bedrijfsprocessen zodat deze op een meer effectieve en efficiënte manier kunnen
worden uitgevoerd. Een grotere toegevoegde waarde voor de organisatie levert ICT als deze wordt ingezet als enabler. Hierbij maakt ICT het mogelijk om
bedrijfsprocessen te veranderen en wordt het mogelijk om bijvoorbeeld lagere prijzen te realiseren of klantgerichter te werken. Ten slotte kan ICT ook worden ingezet als driver waarbij nieuwe business mogelijkheden worden geïnitieerd:
bijvoorbeeld door het internet als nieuw distributiekanaal te gebruiken. ICT wint hierdoor steeds meer aan strategische waarde (Daft 2004). Een goede afstemming (alignment) van de informatievoorziening op de informatiebehoefte is hierbij van wezenlijk belang. Ontwerpers kunnen een systeem opleveren met een zeer geavanceerde functionaliteit maar als deze functionaliteit niet aansluit bij de behoeften van de gebruikers zal het niet worden gebruikt. Het is de taak van de informatieanalist om in het hoofd van de opdrachtgever te kruipen en om precies te bepalen wat hij of zij van de ICT verlangt.
1.6 Systeemontwikkeling
Uit voorgaande paragraaf bleek dat het belang van ICT voor een organisatie erg groot is. Een ICT toepassing die primair gericht is op de ondersteuning van de informatiehuishouding wordt een informatiesysteem genoemd (zie paragraaf 3.2 voor een volledige definitie). De ontwikkeling van een informatiesysteem kan op verschillende manieren worden uitgevoerd. Traditionele
systeemontwikkelingsmethoden verschuiven vanuit een huidige (‘as-is’) situatie naar een nieuwe, toekomstige (‘to-be’) situatie. Moderne
systeemontwikkelingsmethoden maken gebruik van een iteratief ontwerpproces waarbij het ontwikkelingstraject zich een aantal keren herhaalt en waarbij in toenemende mate op details wordt ingegaan. Maar ondanks de verschillende methoden verloopt de ontwikkeling van informatiesystemen nog vaak moeizaam.
Volgens een rapport van de Standish Group (1994) wordt slechts 29% van alle projecten op tijd en binnen het budget afgeleverd. De meerderheid, 53%, wordt wel voltooid maar overschrijdt het budget of voldoet niet aan de functionele eisen.
18% van de systeemontwikkelingsprojecten wordt helemaal afgebroken voor voltooiing. De moeilijkheden die optreden bij softwareontwikkeling zijn inherent aan de kenmerken van software. Deze kenmerken zijn in 1987 al erkend door Frederick Brooks, dit zijn de complexiteit, conformiteit, veranderlijkheid en onzichtbaarheid van software (Brooks 1987). De complexiteit van software wordt veroorzaakt doordat constructies van concepten als data, relaties, algoritmen en functies allemaal in elkaar haken. De conformiteit van software komt voort uit het feit dat software altijd conform een bepaald hardware- en softwareplatform moet werken. Daarnaast moet nieuwe software vaak geïntegreerd worden met bestaande software. Bovendien zijn bedrijfsprocessen continue aan verandering onderhevig.
Software wordt dus ook gekenmerkt door veranderlijkheid. Ten slotte wordt de
onzichtbaarheid van software veroorzaakt doordat de code die verantwoordelijk is
voor een bepaalde output vaak diep en onzichtbaar in het systeem is verborgen.
Door de toegenomen omvang en complexiteit van hedendaagse
informatiesystemen zijn deze kenmerken tegenwoordig niet alleen van invloed op software maar ook op de daar boven liggende systeemeisen. Systeemeisen zijn namelijk complex door tegenstrijdigheden en de vele afhankelijkheden (complexiteit). De eisen moeten worden opgesteld conform interne en externe regelgeving (conformiteit). Daarnaast wil de moderne, flexibele onderneming ondersteund worden door flexibele informatiesystemen waardoor de systeemeisen ook vaak wijzigen (flexibiliteit). Ten slotte kunnen eisen met betrekking tot bijvoorbeeld regelgeving of privacy verborgen blijven achter andere systeemeisen (onzichtbaarheid). Om met deze eigenschappen om te kunnen gaan kan de informatieanalist gebruik maken van vele verschillende instrumenten. Deze instrumenten helpen de analist om de functionaliteit van het informatiesysteem in overeenstemming te brengen met de eisen en wensen van de gebruiker en de opdrachtgever. De vraag welke instrumenten het beste kunnen worden gebruikt zal in de komende hoofdstukken worden beantwoord.
1.7 Samenvatting
In dit hoofdstuk is een inleiding tot het onderzoek gegeven. Het in dit verslag beschreven afstudeeronderzoek is uitgevoerd in opdracht van LogicaCMG en richt zich op de activiteiten van de informatieanalist. Deze informatieanalisten worden doorgaans als ‘consultant’ ingezet bij een klant. Hierbij wordt de analist doorgaans op basis van een inspanningsverplichting gedetacheerd. De informatieanalist heeft als taak om de functionaliteit van het te ontwerpen informatiesysteem af te stemmen op de behoeften van de organisatie. Deze behoeften worden steeds groter en ICT speelt dan ook een steeds grotere rol binnen organisaties. De ontwikkeling van een informatiesysteem is echter een complexe activiteit die de analist
confronteert met vele uitdagingen. Uitdagingen die met behulp van de juiste
instrumenten kunnen worden aangegaan. De vraag welke instrumenten dit zijn
wordt in deze scriptie beantwoord.
2 ONDERZOEKSOPZET
2.1 Inleiding
In dit hoofdstuk zal de opzet van het onderzoek worden beschreven. In paragraaf 2.2 zal een inleiding tot de probleemstelling worden gegeven. De voorlopige probleemstelling van het onderzoek zal in paragraaf 2.3 worden besproken. In paragraaf 2.4 zullen vervolgens de onderzoeksvragen worden geformuleerd. De afbakening van het onderzoek wordt in paragraaf 2.5 toegelicht. Vervolgens wordt in paragraaf 2.6 het onderzoeksmodel geïntroduceerd en wordt in paragraaf 2.7 het gehanteerde plan van aanpak beschreven. De opbouw van het rapport wordt in paragraaf 2.8 in de vorm van een leeswijzer gegeven. Ten slotte worden de informatiebronnen die tijdens het onderzoek zijn geraadpleegd in paragraaf 2.9 gegeven.
2.2 Inleiding tot de probleemstelling
Tijdens de informatieanalyse is de analist verantwoordelijk voor het bepalen van de informatiebehoefte en voor het ontwerpen van een informatievoorziening die in deze behoefte kan voorzien. Deze informatiebehoefte en -voorziening dienen te worden vastgelegd in een model. Er zijn verschillende methoden, technieken en tools beschikbaar die de analist kunnen ondersteunen bij het maken van een model. Maar wat moet er worden weergegeven in het model? Hoe zorgt de analist ervoor dat zijn model voor anderen te begrijpen is? Welke methode, techniek of tool kan de analist gebruiken voor het maken van het model? Welke
tekortkomingen hebben de huidige methoden, technieken en tools? Welke tekortkomingen zijn in de toekomst te verwachten? Dit zijn de vragen waar dit onderzoeksrapport antwoord op zal geven.
2.3 Voorlopige probleemstelling
Dit onderzoek kan worden getypeerd als een probleemoplossend onderzoek.
Hierbij wordt uitgegaan van een probleemsituatie die getransformeerd moet worden naar een verbeterde situatie
1. De voorlopige probleemstelling vormt het beginpunt voor het diagnostisch onderzoek dat in de hoofdstukken 3 tot en met 8 zal worden beschreven. De uitkomst van het diagnostisch onderzoek resulteert uiteindelijke in een definitieve probleemstelling die een concrete vraag formuleert naar de oplossing (zie paragraaf 8.6). Het probleem waar dit onderzoek zich op richt is het ontbreken van inzicht in de instrumenten die helpen te voorzien in de
1 Probleem is een vaktechnische term. Een probleem kan ook worden gezien als een uitdaging of een kans. De toepassing van het probleembegrip is niet beperkt tot situaties waarin er daadwerkelijk klachten zijn. De analyse van verschillende instrumenten voor de informatieanalist kan aanleiding vormen voor het realiseren van maatregelen om kansen die er zijn voor het verbeteren van de analyse, te kunnen benutten.
modelleringsbehoefte van de informatieanalist. De modelleringsbehoefte kan worden omschreven als de mate waarin en de manier waarop de analist elementen uit de werkelijkheid wil weergeven in een model. Deze behoefte is natuurlijk afhankelijk van de doelstellingen van het model. Wat de exacte doelstellingen van een model zijn, zal moeten worden onderzocht maar we kunnen hier al wel vaststellen dat het model in de eerste plaats moet bijdragen aan de afstemming van de informatievoorziening (i.e. het informatiesysteem) op de informatiebehoefte.
Deze doelstelling stelt specifieke eisen aan het model. De voorlopige probleemstelling luidt dan ook
2:
Doelstelling:
Het selecteren van modelleringsmethoden, -technieken en -tools die de informatieanalist zodanig helpen te voorzien in zijn of haar
modelleringsbehoefte dat de specificatie van het informatiesysteem voldoet aan de eisen en wensen van de opdrachtgever.
Vraagstelling:
Wat is de modelleringsbehoefte van de informatieanalist en welke modelleringsmethoden, -technieken en –tools kunnen helpen in deze behoefte te voorzien?
Randvoorwaarden:
•
Praktische toepasbaarheid: het resultaat van het onderzoek dient in de vorm van aanbevelingen, die in de praktijk zijn op te volgen, te worden opgeleverd;
•
Beperking in de tijd: het onderzoek dient in een periode van zes maanden te zijn afgerond.
2.4 Onderzoeksvragen
Het probleem van het onderzoek kan worden opgedeeld in meerdere
onderzoeksvragen. Om inzicht te krijgen in het probleemveld zullen eerst de volgende onderzoeksvragen worden beantwoord:
1. Wat is een informatiesysteem?
2. Wat is een informatieanalyse?
3. Op welke manier kan een informatieanalyse worden vastgelegd?
4. Welke rol spelen modellen tijdens een informatieanalyse?
Vervolgens kan de bedrijfskundige diagnose van de probleemsituatie worden gesteld. In de diagnose wordt het functioneren van het probleemveld onderzocht
2 De probleemstelling bestaat uit een doelstelling, vraagstelling en de randvoorwaarden (De Leeuw 2002)
en beoordeeld. Om tot een juiste diagnose te komen zullen de volgende onderzoeksvragen worden beantwoord:
5. Welke methoden, technieken en tools kunnen het opstellen van een specificatie ondersteunen?
6. Welke methoden, technieken en tools worden er door de informatieanalist gebruikt?
7. Wat is de huidige en toekomstige modelleringsbehoefte van de informatieanalist?
Na het stellen van de diagnose kan deze worden uitgewerkt in een ontwerpfase.
Tijdens deze fase wordt er naar een concrete oplossing voor de probleemsituatie gezocht. Om tot een juist ontwerp te komen zullen de volgende onderzoeksvragen worden beantwoord:
8. Welke evaluatiecriteria kunnen we hanteren voor de waardering van de methoden, technieken en tools voor de informatieanalist?
9. Welke methoden, technieken en tools zouden aan de huidige en toekomstige modelleringsbehoefte van de informatieanalist kunnen voldoen?
Nadat het ontwerp van de oplossing is vastgesteld, is deze gereed om te worden ingevoerd om zodoende het organisatieprobleem te verhelpen.
2.5 Afbakening van het onderzoek
Afbakening van het onderzoek moet plaats vinden om de opdracht met de beschikbare middelen uit te kunnen voeren. Om deze reden zullen alle aspecten die tijdens systeemontwikkeling voorkomen worden onderzocht maar blijft de technische realisatie van het systeem buiten beschouwing. Het onderzoek beperkt zich ook tot de methoden, technieken en tools die de vastlegging van de
informatieanalyse kunnen ondersteunen. Technieken en methoden voor het vergaren en toetsen van de gespecificeerde informatie zullen niet worden
geëvalueerd. Ten slotte dienen de modelleringsmethoden, technieken en tools die tot het onderzoeksgebied behoren, vandaag de dag relevant te zijn voor de praktijk.
Het is niet de bedoeling een historisch en uitputtend overzicht te geven van alle methoden, technieken en gereedschappen.
2.6 Conceptueel onderzoeksmodel
Het conceptueel model geeft de verschillende concepten uit het probleemgebied
weer en de relaties tussen deze concepten. Figuur 1 geeft een grafische weergave
van het onderzoek. Om tot criteria voor het beoordelen van de verschillende
instrumenten (i.e. methoden, technieken en tools) te komen zal een inventarisatie
worden gemaakt van de huidige en de toekomstige modelleringsbehoefte.
Daarnaast zal inzicht in de theoretische en praktische achtergrond bijdragen aan de criteria.
Figuur 1 Conceptueel onderzoeksmodel
Na een inventarisatie van het aanbod aan methoden, technieken en tools zullen de beoordelingscriteria worden toegepast. Deze toepassing zal vervolgens leiden tot een selectie van instrumenten die aan de modelleringsbehoefte kunnen helpen voldoen.
2.7 Plan van aanpak
Om structuur te geven aan het verloop van het onderzoek wordt gebruik gemaakt van een onderzoeksmodel. Doordat de analisten al geruime tijd gebruik maken van verschillende methoden, technieken en gereedschappen, kan het onderzoek worden getypeerd als een onderzoek tot herontwerp. Bij een opdracht tot
herontwerp is het van belang om een goede diagnose te maken en een scherp beeld te krijgen van de tekortkomingen in de huidige situatie. Het onderzoeksmodel is opgezet volgens een variant op het DOV-model (Diagnose, Ontwerp, Verandering) van De Leeuw (2003). Dit model is geschikt om te dienen als aanpak voor
managementproblemen waarbij niet alleen de
hoe-vragen (hoe moeten we het
probleem oplossen?), maar ook de
wat-vragen (wat is eigenlijk het probleem?) aan
de orde komen. In het onderzoeksmodel (zie Figuur 2) staat de diagnosefase
centraal. Bij de definiëring van het centrale probleem van de organisatie kan
onderscheid worden gemaakt tussen het instrumentele en het functionele
probleem (De Leeuw 2002). Instrumentele problemen zijn problemen in de
vormgeving en inrichting van de organisatie en functionele problemen zijn
problemen in de output van de organisatie. Het centrale probleem is altijd een functioneel probleem. Instrumentele en functionele problemen zijn met elkaar verbonden als oorzaak en gevolg. Het instrumentele probleem is een uitspraak over een oorzaak. Deze oorzaak is nog niet bekend en zal in de loop van het onderzoek duidelijk moeten worden. Het functionele oordeel zegt iets over het gevolg van de oorzaak. Dit gevolg is al wel bekend en is in paragraaf 2.3 geformuleerd als “het ontbreken van inzicht in de instrumenten die helpen te voorzien in de
modelleringsbehoefte van de informatieanalist”.
Herontwerp
Instrumenten van de
informatieanalist Model van de instrumenten
van de informatieanalist Diagnose:
Ontwerpdoelstellingen Functioneel probleem Instrumenteel probleem Parameters:
Figuur 2 Model van het onderzoek
Tijdens de diagnosefase zal de oorzaak-gevolg relatie tussen het instrumenteel en het functioneel probleem precies worden gedefinieerd. Met behulp van het inzicht in deze causale relatie zullen de ontwerpdoelstellingen worden geformuleerd. Deze ontwerpdoelstellingen zullen gezamenlijk het uitgangspunt voor de fase van herontwerp vormen (hoofdstuk 9). Het herontwerp zal kunnen worden toegepast op de modelleringsbehoefte en de mix van instrumenten van de informatieanalist.
Een juist herontwerp zal uiteindelijk een positieve invloed moeten hebben op het instrumentele en het functionele probleem en op de nieuwe
ontwerpdoelstellingen.
2.8 Leeswijzer
De relaties tussen de hoofdstukken van dit rapport zijn weergegeven in Figuur 3.
Naar aanleiding van de voorlopige probleemstelling uit paragraaf 2.3, zal eerst inzicht in het probleemveld worden gekregen door achtereenvolgens te kijken naar het aspect van informatieplanning (hoofdstuk 3), de specificatie van een informatieanalyse (hoofdstuk 4) en naar modellen (hoofdstuk 5). Deze
hoofdstukken sluiten op elkaar aan en gaan van een algemene beschouwing van informatieanalyse tot een specifiek onderdeel van de informatieanalyse, het modelleren. Dit inzicht in het probleemveld vormt de input voor de
bedrijfskundige diagnose van de probleemsituatie. Hierbij wordt in hoofdstuk 6 een inventarisatie gegeven van de methoden, technieken en tools en geeft hoofdstuk 7 inzicht in de praktische achtergrond van het probleemgebied.
Figuur 3 Hoofdstukindeling
De hoofdstukken 3 tot en met 7 geven uiteindelijk genoeg inzicht om in hoofdstuk
8 de diagnose te kunnen stellen en om een analyse van de modelleringsbehoefte te
kunnen maken. Deze diagnose wordt samengevat in de formulering van de
definitieve probleemstelling aan het einde van hoofdstuk 8, in paragraaf 8.6. Deze
definitieve probleemstelling formuleert een concrete vraag naar de oplossing
waarnaar in hoofdstuk 9 zal worden gezocht. De manier waarop deze oplossing dient te worden geïmplementeerd wordt in hoofdstuk 10 beschreven.
2.9 Informatiebronnen
Dit onderzoeksrapport is gebaseerd op informatie die verkregen is uit interviews, literatuur en uit een vragenlijst. Tijdens het onderzoek zijn er interviews gehouden en verschillende gesprekken gevoerd met ICT consultants. Deze interviews en gesprekken hebben gezamenlijk het inzicht in de praktijk gegeven. Door middel van een literatuurstudie is een theoretisch kader opgesteld voor het onderzoek. Op basis van dit theoretische kader en het inzicht in de praktijk is vervolgens een vragenlijst opgesteld die is afgenomen onder de informatieanalisten van LogicaCMG.
2.10 Samenvatting
In dit hoofdstuk is de onderzoeksopzet beschreven. Hierbij is gesteld dat het gebrek aan inzicht in het landschap van de methoden, technieken en tools zou kunnen leiden tot tekortkomingen in de afstemming van de informatievoorziening op de informatiebehoefte. Om deze tekortkomingen op te kunnen sporen is het van belang om inzicht te krijgen in de modelleringsbehoefte. Dit inzicht zou moeten leiden tot een herontwerp waarin de juiste methoden, technieken en tools worden geselecteerd. Het onderzoek wordt uitgevoerd volgens een
onderzoeksmodel dat gebaseerd is op het DOV-model van de Leeuw (Leeuw 2003).
3 INFORMATIEPLANNING
3.1 Inleiding
In dit hoofdstuk kijken we naar het informatiesysteem en de informatieanalyse.
Hierbij zullen de eerste twee deelvragen uit de onderzoeksopzet (zie paragraaf 2.4) worden beantwoord. Deze deelvragen zijn: ‘Wat is een informatiesysteem?’ en
‘Wat is een informatieanalyse?’. Hiervoor zal in paragraaf 3.2 de rol van het informatiesysteem in de organisatie worden besproken. Paragraaf 3.3 zal de rol van de informatieanalist toelichten. Vervolgens zal de inhoud van een typische
informatieanalyse in paragraaf 3.4 worden behandeld. De informatie die de analist tijdens de informatieanalyse verzameld wordt in paragraaf 3.5 toegelicht en de verschillende niveaus van detail die daarbij worden onderscheiden vormen het onderwerp van paragraaf 3.6.
3.2 Informatiesysteem
Om de plaats van het informatiesysteem in een organisatie aan te kunnen geven, kan gebruik worden gemaakt van de systeembenadering. Deze benadering wordt gekenmerkt door de beschouwingswijze van de werkelijkheid als een systeem (Emery 1981). Hierbij kan de organisatie als een systeem worden beschouwd met een bepaalde input, besturing en output. Wanneer men de organisatie in zijn geheel als hoogste aggregatieniveau beschouwt
3, wordt de organisatie het objectsysteem genoemd (De Leeuw 2002)
4. Een systeembenadering maakt onderscheid tussen deelsystemen en beschouwt de samenhang tussen deze deelsystemen. De informatiehuishouding van een organisatie kunnen we beschouwen als een deelsysteem van de organisatie (Hopstaken et al. 1991) en heeft als zodanig ook de drie kenmerken van een organisatie: mensen, activiteiten en middelen. De informatiehuishouding onderscheidt zich van de rest van de organisatie op het gebied van de activiteiten. De activiteiten binnen een informatiehuishouding zijn gericht op het informeren van de klanten van de organisatie of degene die de activiteiten in de rest van de organisatie uitvoeren.
Hoe deze informatiehuishouding moet worden vormgegeven wordt opgenomen in een informatiestrategie. In deze informatiestrategie wordt ook de rol van het informatiesysteem beschreven.
3 Bij de beschrijving van een organisatie moet ‘organisatie’ gelezen worden als dat gedeelte van een organisatie dat voor het onderzoek van belang is. Het kan dus ook heel goed een afdeling van een organisatie zijn.
4 Een andere term voor objectsysteem is de Universe of Discourse (UoD).
In het kader van het onderzoek hanteren we de volgende definitie van een informatiesysteem (Hopstaken et al. 1991):
“Een informatiesysteem is een deelsysteem van een systeemgebied, betreffende een samenhangend geheel van bedrijfsprocessen, gegevens, programmatuur, mensen, technische uitrusting, methoden en financiën, ten behoeve van de geformaliseerde informatiehuishouding van
bedrijfsprocessen.”
Volgens deze definitie ondersteunt een informatiesysteem de
informatiehuishouding. Dit doet een informatiesysteem door bepaalde
bedrijfsprocessen van een organisatie geheel of gedeeltelijk te automatiseren. Een voorbeeld van een volledig geautomatiseerd bedrijfsproces is het beschikbaar maken van de telefoonrekening via het internet. Zonder tussenkomst van mensen is het mogelijk om de informatie die nodig is voor het opmaken van de factuur volledig automatisch te verzamelen en te publiceren op het internet. Het informatiesysteem staat vaak in het hart van de organisatie. Organisaties als banken en verzekeraars kunnen vaak al niet meer functioneren zonder hun informatiesystemen en voor e-commerce ondernemingen geldt zelfs dat er zonder informatiesysteem ook geen bedrijf is.
3.3 Informatieanalist
Bij het ontwerpen van het informatiesysteem zijn verschillende mensen
betrokken. In de beginjaren van systeemontwikkeling waren bij de ontwikkeling van het softwaresysteem alleen programmeurs betrokken. Maar met het toenemen van de omvang en de complexiteit van softwaresystemen ontstond al snel een noodzaak voor diverse vaardigheden. De expertise van programmeurs ligt voornamelijk in de technologische aspecten van het systeem. Deze mensen zijn niet gespecialiseerd in het achterhalen van de behoeften van gebruikers en in het vastleggen van de functionele eigenschappen. Volgens Dennis et al. zijn
tegenwoordig tijdens het systeemontwikkelingstraject technische,
organisatorische, analytische, sociale en ethische vaardigheden nodig (Dennis et al.
2003). Elk projectlid is gespecialiseerd in één van deze vaardigheden maar de persoon die over al deze vaardigheden moet beschikken is de informatieanalist.
Deze vaardigheden heeft de analist nodig om tijdens een informatieanalyse de bedrijfsproblemen, bedrijfsprocessen en informatiebehoeften te kunnen analyseren en om vervolgens voorstellen te kunnen doen voor oplossingsalternatieven
(Pollaert et al. 2002). De informatieanalist stelt de eisen voor de
informatievoorziening op en bepaalt daarmee de kaders voor de verdere
ontwikkeling van het informatiesysteem. Een analist werkt nauw samen met
toekomstige gebruikers, projectmanagers, productspecialisten, functioneel
ontwerpers en businessanalisten. Omdat een analist met zowel bedrijfskundige,
technische, economische als politieke aspecten in aanraking komt, vervagen de grenzen tussen de functies vaak. In een typisch traject van informatieanalyse ontvangt de analist het inzicht in de organisatorische processen van één of meerdere businessanalisten en levert hij zijn inzicht in de informatiestromen aan functioneel ontwerpers. De scheidslijn tussen deze functies valt echter niet
eenduidig vast te leggen (zie Figuur 4). Het komt ook voor dat er bij projecten geen businessanalist aanwezig is. Dan ontstaat er een gecombineerde functie van
businessanalist en informatieanalist waarbij de informatieanalist direct betrokken is bij het inrichten van de organisatorische processen. Aan de andere, technische kant komt het ook vaak voor dat de analist tegelijkertijd de functie van functioneel ontwerper vervult. Hierbij moet de analist zijn informatieanalyse ook uitwerken tot een gedetailleerd systeemontwerp.
Functioneel ontwerp Business analyse
Informatieanalyse
Figuur 4 De inhoud van de verschillende competenties overlappen elkaar
3.4 Informatieanalyse
Het typische traject van informatieanalyse verloopt volgens zeven stappen (zie Figuur 5) die over drie fasen kunnen worden verdeeld
5. Tijdens de eerste drie stappen wordt de informatiebehoefte vastgesteld:
1. De informatieanalist bepaalt de informatiebehoefte in het businessdomein.
Dit businessdomein bestaat voor de analist uit de domeinexperts (de opdrachtgever(s) en de gebruiker(s)) en uit de werkelijkheid;
2. De analist structureert deze informatiebehoefte in een model van de huidige situatie;
3. De analist legt dit model ter verificatie voor aan de domeinexpert(s);
5 Dit proces van de informatieanalyse is een zuiver theoretisch beeld. In de praktijk blijkt dat het per
informatieanalist en per organisatie kan verschillen welke stappen in meer of mindere mate deel uitmaken van de informatieanalyse (zie paragraaf 3.3).
Deze drie stappen worden in iteraties uitgevoerd totdat de domeinexpert zich kan vinden in de analyse van de informatiebehoefte. Als dit het geval is dan komt de analyse in de tweede fase terecht.
Figuur 5 De elementen van de informatieanalyse
In de tweede fase wordt de informatievoorziening vastgesteld die er voor moet zorgen dat er aan de informatiebehoefte wordt voldaan:
4. De analist ontwerpt een oplossing voor het informatievraagstuk en legt deze vast in een model van de toekomstige situatie;
5. De analist legt dit model ter goedkeuring voor aan de domeinexpert(s);
Ook deze stappen worden in iteraties uitgevoerd totdat de analist en de domeinexpert het eens zijn over de informatievoorziening.
In de derde fase van de informatieanalyse wordt een initieel ontwerp van het toekomstige informatiesysteem gemaakt dat de informatievoorziening zal verzorgen. In deze fase wordt meer detail vastgelegd en ligt de focus op het toekomstige informatiesysteem:
6. De analist structureert de oplossing en legt deze vast in een model van het
systeem;
7. De analist legt dit gedetailleerde systeemmodel ter verificatie en ter goedkeuring voor aan de functioneel ontwerper.
Wanneer de ontwerper dit model heeft goedgekeurd zal hij of zij het ontwerp vertalen naar een specifiek ontwikkelplatform waarna het door programmeurs zal worden gebouwd.
3.5 Informatieverzameling
Tijdens de analyse analyseert de informatieanalist in de eerste plaats de processen, de informatie en de procedures (bedrijfsregels). Daarnaast houdt een analist ook rekening met commercie, organisatie, personeel, administratie, financiën, infrastructuur, technologie, huisvesting, juridische kwesties, ergonomie en
logistiek
6. Welke informatie er verder nodig is om de gewenste bedrijfsprocessen te ondersteunen, is afhankelijk van de eisen en wensen van de organisatie. Deze eisen en wensen worden doorgaans functionele eisen en niet-functionele eisen genoemd.
Een functionele eis wordt door Kotonya et al. (1998) gedefinieerd als “een vastgelegde systeemfunctie of systeembeperking”. Een systeemfunctie beschrijft wat het systeem doet (bijvoorbeeld: de telefoonrekening van de klant wordt op de website weergegeven) en een systeembeperking beschrijft een regel die te allen tijde moet worden opgevolgd (bijvoorbeeld: de telefoonrekening kan pas worden ingezien als de klant is ingelogd op de website). Wanneer de informatieanalist dergelijke eisen en wensen bepaalt, zijn sociale, communicatieve en management vaardigheden veel belangrijker dan de technische vaardigheden. Een analist ontdekt de systeemeisen via consultatie waarbij gebruikers en experts uit het probleemdomein betrokken zijn. De functionele eisen kunnen via traditionele middelen worden verkregen zoals interviews, vragenlijsten, observaties en documentanalyses of via moderne methoden als Joint Application Development (JAD), prototyping en brainstorming.
Niet-functionele eisen zijn eisen over o.a. het uiterlijk, de prestaties, de beveiliging en de betrouwbaarheid die van het systeem verlangd worden (Maciaszek 2005).
Niet-functionele eisen kunnen een rol spelen tijdens een analyse maar spelen over het algemeen slechts een indirecte rol. De niet-functionele eisen zijn voornamelijk van belang tijdens de ontwerpfase waarin er beslissingen worden genomen met betrekking tot de architectuur van het systeem (Dennis et al. 2003).
3.6 Niveau van detail
Tijdens de informatieanalyse begint men met een analyse op bedrijfskundig niveau met de vraag naar onder andere het bedrijfsdoel, de strategie en de
6 Afkomstig van het acroniem COPAFITHJEL (Pollaert et al. 2002)
bedrijfsprocessen. Daarna worden er langzaam stappen gemaakt richting het uiteindelijke technische ICT-systeem. Om de verschillende stappen in kaart te brengen kan er een hiërarchie worden aangebracht. Deze hiërarchie bestaat uit vijf niveaus (Pollaert et al. 2002):
•
Bedrijfsniveau: Op dit niveau worden doel, strategie, producten en markten van de organisatie beschreven. Dit geeft het hoogste referentieniveau voor de behoeften waar het te ontwerpen systeem in moet voorzien;
•
Bedrijfsprocesniveau: Op dit niveau wordt in kaart gebracht wat de formele en informele processen zijn. Deze worden beschreven om te bepalen welke processen nodig zijn om de doelen uit het bedrijfsniveau te bereiken;
•
Informatievoorzieningniveau: Op dit niveau wordt bepaald wat de organisatie moet weten en wat het aan gegevens moet verwerken om de processen uit het bedrijfsprocesniveau uit te kunnen voeren. De informatiebehoefte en de gebruikerseisen spelen hierbij de hoofdrol;
•
ICT-systeemniveau: Op dit niveau wordt bepaald welke gegevensverwerkende systemen nodig zijn om aan de informatievoorziening te kunnen voldoen;
•
Infrastructuurniveau: Op dit niveau wordt bepaald welke hardware, netwerken en software nodig zijn. Dit is het meest technische niveau.
Tot een typische informatieanalyse behoren doorgaans het bedrijfsprocesniveau en het informatievoorzieningniveau, maar dit kan per organisatie verschillen.
3.7 Samenvatting
In dit hoofdstuk zijn de eerste twee deelvragen van het onderzoek uitgewerkt.
Deze deelvragen luidden: ‘Wat is een informatiesysteem?’ en ‘Wat is een
informatieanalyse?’. Het informatiesysteem moet de informatiehuishouding van de organisatie ondersteunen. Tijdens de ontwikkeling van het informatiesysteem is de informatieanalist actief in het voortraject en stelt de eisen voor de
informatievoorziening op. Daarmee bepaald hij of zij de kaders voor de verdere ontwikkeling van het informatiesysteem. Tijdens een typisch traject van
informatieanalyse worden zeven stappen doorlopen. Deze stappen kunnen worden verdeeld over drie fasen: het bepalen van de informatiebehoefte, het ontwerpen van een informatievoorziening en het maken van een initieel systeemontwerp.
Tijdens een informatieanalyse worden er verschillende vormen van informatie verzameld waaronder de eisen en wensen van de organisatie. Deze eisen en wensen worden verdeeld in functionele en niet-functionele eisen en wensen. De informatie wordt op verschillende niveaus vastgelegd. Tot een typische
informatieanalyse behoort de informatie op het niveau van de bedrijfsprocessen en
de informatievoorziening.
4 SPECIFICATIE VAN DE ANALYSE
4.1 Inleiding
In dit zal een antwoord worden gegeven op de derde deelvraag van het onderzoek (zie paragraaf 2.4). Deze deelvraag luidt: ‘Op welke manier kan een
informatieanalyse worden vastgelegd?’. In paragraaf 4.2 zullen de verschillende activiteiten die tijdens de informatieanalyse worden uitgevoerd worden besproken.
Een theoretische benadering van de informatieanalyse wordt in paragraaf 4.3 gegeven. Het traject van een ideale analyse verloopt volgens de processen van formalisering en conceptualisering, deze processen worden in paragraaf 4.4 en 4.5 besproken. In paragraaf 4.6 zal ten slotte worden ingegaan op de theoretische inhoud van de specificatie.
4.2 Activiteiten
Het traject van een typische informatieanalyse verloopt volgens drie fasen: het bepalen van de informatiebehoefte, het ontwerpen van een informatievoorziening en het maken van een initieel systeemontwerp (zie paragraaf 3.4). Volgens
Loucopoulos (1995) kunnen tijdens deze fasen drie verschillende activiteiten worden onderscheiden:
•
Elicitatie: het vergaren van de informatie;
•
Specificatie: het vastleggen van de informatie;
•
Validatie: het toetsen van de informatie.
Elicitatie
Oplossing:
Informatievoorziening Kennis uit
probleemdomein
Beschrijving van het probleemdomein
Resultaten van de validatie Verzoek tot aanvullende
informatie
Specificatie Validatie
Beschrijving
Beschrijving Probleem:
Informatiebehoefte
Figuur 6
Activiteiten tijdens de analyseDeze drie stappen worden in een continu proces doorlopen waarbij ze regelmatig worden afgewisseld. In dit onderzoek richten we ons specifiek op het proces van specificatie en de instrumenten die dit proces ondersteunen. Om deze reden zullen we ons in het bijzonder richten op de beschrijving van de informatiebehoefte en de informatievoorziening (zie Figuur 6).
Het specificeren kan echter niet helemaal los worden gezien van de fasen van elicitatie en validatie. Tijdens het proces van elicitatie wordt namelijk bepaald welke informatie zal moeten worden gespecificeerd. Daarnaast is de manier waarop het proces van validatie verloopt sterk afhankelijk van de manier waarop de informatie is gespecificeerd. De drie activiteiten zullen in de volgende subparagrafen verder worden toegelicht.
4.2.1 Elicitatie
Tijdens de fase van elicitatie (letterlijk ‘ontlokking’) probeert de analist zoveel mogelijk relevante informatie te verzamelen waardoor hij of zij inzicht krijgt in de probleemsituatie. Deze informatie dient te worden verkregen uit bijvoorbeeld documentatie, toekomstige gebruikers, de opdrachtgever, bestaande software systemen, en vele andere mogelijke bronnen. De fase van elicitatie draait helemaal om het
begrijpenvan het probleem- en oplossingsgebied. De analist dient hierbij bekend te raken met het domein en de terminologie uit het domein.
4.2.2 Specificatie
Tijdens de fase van specificatie worden de elementen van de huidige en
toekomstige situatie beschreven in modellen. De input voor dit proces vormt de verworven kennis uit de fase van elicitatie. Deze kennis wordt vastgelegd in documenten en modellen. Het product van de specificatie vormt uiteindelijk een blauwdruk van het te bouwen informatiesysteem. Een specificatie dient twee hoofddoelen:
•
De specificatie ondersteunt het inzicht van de informatieanalist;
•
De specificatie ondersteunt de communicatie van het inzicht van de informatieanalist naar de betrokkenen.
Vooral de tweede doelstelling stelt specifieke eisen aan de specificatie. Hierbij dient de specificatie als hulpmiddel voor het uitwisselen van informatie tussen de betrokkenen. Dit stelt hoge eisen aan de structuur van de specificatie. De
betrokkenen kunnen grofweg verdeeld worden in twee doelgroepen: de
domeinexpert(s) en de ontwerper(s). De domeinexpert dient inzicht te krijgen in
de geboden oplossing om na te kunnen gaan of deze ook daadwerkelijk aan zijn
behoeften voldoet. De ontwerper heeft het inzicht nodig om te bepalen of de
oplossing technisch uitvoerbaar is en om uiteindelijk het informatiesysteem te
bouwen. Hierbij staat de analist voor een grote uitdaging, want beide doelgroepen
hebben een compleet verschillende achtergrond. De domeinexperts zijn
gespecialiseerd in het optimaliseren van de bedrijfsvoering en de ontwerpers zijn gespecialiseerd in het ontwerpen van de technische oplossingen. Het is de taak van de informatieanalist om een brug te slaan tussen deze twee verschillende
disciplines. Daarbij weerspiegelt de specificatie van de informatiebehoefte en - voorziening uiteindelijk het wederzijdse begrip dat de domeinexperts, analisten en ontwikkelaars hebben van het probleemgebied. Het specificeren en modelleren van de analyse zal in de paragrafen 4.3 tot en met 4.6 in detail worden besproken.
4.2.3 Validatie
Met behulp van instrumenten zijn modellen gemakkelijk te controleren op correctheid, maar dit wil nog niet zeggen dat het ook de juiste modellen zijn. Wat soms wordt beschouwd als het probleem van de gebruiker kan in de werkelijkheid wel helemaal niet zo zijn. Deze misvatting kan het gevolg zijn van fouten die zijn opgetreden tijdens de elicitatie en de specificatie (Loucopoulos et al. 1995). Deze fouten kunnen er toe leiden dat er tijd en middelen worden gestoken in het oplossen van het verkeerde probleem. Om deze fouten te voorkomen dient het inzicht van de analist te worden getoetst bij de domeinexpert. Dit gebeurt tijdens de validatie. De analist kan hierbij gebruik maken van technieken als prototyping, simulatie en zijn model uitdrukken in natuurlijke taal.
4.3 Analyse en synthese
Voor een theoretische benadering van de specificatie kunnen we gebruik maken van een theorie uit de ontwerpleer. Volgens Alexander (1966) kunnen we tijdens het ontwerpen twee, elkaar afwisselende, mentale bezigheden onderscheiden:
analyse en synthese. Met analyse wordt bedoeld het beter leren begrijpen van het probleem en onder synthese wordt het bedenken en concretiseren van de
oplossing verstaan. Dit onderscheid kunnen we ook maken tijdens de ontwikkeling van software. Dit is op een inzichtelijke manier uitgebeeld door Hesse (1983).
Hesse ziet het ontwikkelingsproces als een traject in een tweedimensionale ruimte
van een bepaald beginpunt naar een eindpunt (zie Figuur 7). Het beginpunt R
(Requirement) wordt gevormd door de geformuleerde specificaties en het eindpunt
C (Code) door de programmacode. De twee dimensies van het vlak zijn de mate
van abstractie van de specificatie (van abstract naar concreet) en de mate van
formalisering van de specificatie (van informeel tot formeel). De weg van R naar C,
langs welke route dan ook, is tegelijkertijd een formalisering van de specificaties en
een concretisering tot de uiteindelijke programmacode. In de praktijk is elke weg
van R naar C mogelijk. Volgens Hesse is de ideale weg, de weg waarbij eerst het
horizontale traject in zijn geheel wordt afgelegd en dan het verticale traject in zijn
geheel. Dat wil zeggen eerst het volledig formaliseren van de specificaties alvorens
te gaan concretiseren.
Een ideaal dat met behulp van moderne methoden en technieken dicht zou kunnen worden benaderd (zie paragraaf 7.5.3). Volgens Hesse is de praktijk echter dat men vaak eerst concretiseert en daarna pas formaliseert. Dat wil zeggen dat de software vaak op een informele manier tot in de kleinste details wordt beschreven en vervolgens meteen wordt omgezet in programmacode. In de praktijk blijkt het zo snel mogelijk schrijven van programmacode erg verleidelijk. In veel gevallen wordt dit ook nog eens gestimuleerd door projectleiders die de voortgang van een softwareproject het liefst afmeten aan het aantal geproduceerde regels code.
abst ract ie
Figuur 7 Analyse en synthese
4.4 Formaliseren
In paragraaf 4.2.2 is vastgesteld dat de specificatie het wederzijdse begrip weerspiegelt dat de domeinexperts, analisten en ontwikkelaars hebben van het probleemgebied. Om tot dit wederzijds begrip te komen dient er een goede communicatie te zijn tussen de betrokkenen. Communicatie in zijn
oorspronkelijke betekenis is het delen van gedachten tussen mensen. Voor wat betreft de informatieanalyse heeft de analist deze gedachten vastgelegd in de specificatie. Hierbij maakt de analist gebruik van een bepaalde notatietechniek.
Brinkkemper (1990) identificeert drie categorieën van notatietechnieken: formele,
semi-formele en informele notatietechnieken.
•
Formele technieken zijn technieken waarvan de syntaxis en de semantiek volledig zijn gedefinieerd. Een voorbeeld van een formele notatietechniek is de algebra: bij het formuleren van een wiskundige formule ligt van ieder element uit de formule de manier van noteren vast (een zes wordt altijd als een ‘6’
getekend) en ligt de betekenis van dit element vast (de ‘6’ staat altijd precies voor het getal zes);
•
Semi-formele technieken zijn technieken waarvan de syntaxis van de notatie volledig gedefinieerd is maar waarbij de semantiek niet helemaal is vastgelegd.
In regels is precies vastgelegd welke tekens wel of niet mogen worden gebruikt. Maar de waarde die aan deze tekens moet worden toegekend kan doorgaans niet expliciet worden vastgelegd omdat deze overeen moet komen met de elementen uit het domein (de echte wereld);
•
Informele technieken zijn technieken waarbij geen regels en beperkingen zijn gedefinieerd voor het noteren van informatie. Zowel de syntaxis als de
semantiek is niet vastgelegd. Natuurlijke taal en ongestructureerde plaatjes zijn voorbeelden van informele notatietechnieken.
Een notatietechniek voor het specificeren van het informatiesysteem dient volgens Brinkkemper (1990) een semi-formele techniek te zijn. Een goede definitie van de syntaxis is nodig om dubbelzinnigheden te voorkomen en uitvoerbaarheid
(automatische opslag, verificatie, transformatie en simulatie van modellen) mogelijk te maken. De semantiek van de techniek moet niet volledig vastgelegd zijn omdat deze overeen moet komen met de elementen uit het domeingebied. Een gebied dat voor ieder informatiesysteem weer anders is.
Een theorie die het idee van Brinkkemper ondersteund is de Sapir-Whorf hypothese (Whorf B.L. 1956). De Sapir-Whorf hypothese (ook wel linguïstische relativiteit genoemd) stelt dat de waarneming van de werkelijkheid sterk afhankelijk is van de taal die iemand gebruikt om deze waarneming te communiceren. Deze hypothese gaat uit van het idee dat de activiteit van het beschrijven voor een groot deel overeenkomt met de activiteit van classificeren.
Dit wil zeggen dat wanneer men bepaalde elementen uit de werkelijkheid
beschrijft, men eigenlijk voornamelijk bezig is om deze elementen in een bepaalde categorie in te delen alvorens ze uit te drukken in een taal. De hypothese bestaat vervolgens uit twee delen
7:
•
De structuur die iemand in de werkelijkheid aanbrengt wordt bepaald door de taal die men gebruikt om deze structuur te beschrijven;
7 De hypothese is gepubliceerd in 1956 en is sindsdien in verschillende empirische studies weerlegd maar ook bevestigd. De uitkomst van deze studies is dat er enige nuance in de hypothese moet worden aangebracht: er zijn cognitieve processen waar de taal geen invloed op heeft en de hypothese richt zich voornamelijk op de onbewuste structuren van de taal en niet op de bewuste, lexicale categorieën (Gumperz et al. 1996).
