TIJD VOOR KW ALlTElT WERKEN AAN BETERE INFORMAT1ESYSTEMEN

TIJD VOOR KW ALlTElT WERKEN AAN BETERE INFORMAT1ESYSTEMEN

TUD VOOR KWALlTElT WERKEN AAN BETERE INFORMATIESYSTEMEN

PROEFSCHRIFI'

ter verkrijging van de graad van doctor aan de Technische Universiteit Eindhoven, op gezag van de Rector Magnificus, prof.dr. J.H. van Lint, voor een commissie aangewezen door het College van Dekanen in het openbaar te verdedigen op 15 apri11994 om 16.00 uur

door

JOSEPHUS JACOBUS MARIA TRIENEKENS Geboren te Breda

THESIS PUBLISHERS AMSTERDAM 1994

Dit proefschrift is goedgekeurd door de promotoren: prof.dr. T.M.A. Bemelmans en prof.dr.ir. J.C. Wortmann

Voor Ine, Iris, Max en mijn ouders

VOORWOORD

Kwaliteit neemt snel in belang toe in de infonnatiesystemenwereld. De jaren negentig worden door velen reeds bestempeld als het kwaliteitstijdperk. De slogan 'Tijd voor kwaliteit', die dit boek als titel draagt, is in toenemende mate van toepassing op het ontwikkelen van infonnatiesystemen. Naast het op tijd en tegen afgesproken kosten realiseren en leveren eisen afnemers een meerwaarde die kwaliteit wordt genoemd. Makers van software en informatiesystemen pogen aan die meerwaarde te voldoen door het ontwikkelwerk verder te structureren en te standaardiseren. Typerend voor deze kwaliteitsbeweging is dat niet wordt gestreefd naar geheel nieuwe ontwikkelmethoden en -technieken, veel meer wordt het accent gelegd op gerichte verbeteringen op deelgebieden binnen de bestaande aanpak en werkwijzen. Deze houding van makers blijkt ook uit empirisch onderzoek waarvan in dit boek verslag wordt gedaan.

Kwaliteit krijgt bij het ontwikkelen van infonnatiesystemen slechts betekenis wanneer men een goed geïntegreerd beeld heeft van de verschillende aspecten van het ontwikkelwerk. Daarom beperkt dit boek zich niet tot één aspect, bijvoorbeeld het inhoudelijke modelleren van informatiesystemen. Vanuit een samenhangend beeld van de aspecten modelleren, beheersen, leren, veranderen en balanceren wordt de betekenis van kwaliteit beschreven. Het ontwikkelaspect balanceren, ofwel het maken van afwegingen tijdens het ontwikkelwerk, speelt daarin een centrale rol Kwaliteitsopvattingen in zowel theorie als praktijk vertonen grote verschillen. Dit vraagt om ordening en evaluatie. De ordening maakt duidelijk dat kwaliteit onlosmakelijk verbonden is met het perspectief van waaruit kwaliteit wordt beschouwd en het soort object waarvan men de kwaliteit wenst te bepalen. Drie objectklassen worden onderscheiden, te weten produkten, processen en middelen. Gesteld wordt dat binnen elk van deze objectklassen duidelijke omschrijvingen van objecten en hun eigenschappen nodig zijn. In dat verband wordt in dit boek de stelling 'eerst weten voordat kan worden gemeten' gehanteerd. Het specificeren van kwaliteitseisen heeft tot nu toe relatief weinig aandacht gekregen in literatuur en praktijk. Uit de evaluatie van kwaliteitsopvattingen blijkt dat dit een van de belangrijkste tekortkomingen is in het omgaan met kwaliteitseisen. Hoewel algemeen bekend is dat het voldoen aan kwaliteitseisen in belangrijke mate het succes van een informatiesysteem bepaalt, wordt in de huidige methoden en werkwijzen vrijwel geen aandacht besteed aan het afleiden en specificeren daarvan. In dit boek wordt een aanzet ontwikkeld voor een methode voor het specificeren van kwaliteitseisen. Alleen door tijd te besteden aan de bepaling van de kwaliteitsbehoeften van organisaties en afnemers wordt het mogelijk daadwerkelijk kwaliteit van informatiesystemen te leveren. Ook op die manier moet de titel van dit boek 'Tijd voor kwaliteit' worden geïnterpreteerd.

Jos J .M. Trienekens

INHOUD

Voorwoord 1

Inleiding, probleemstelling en verantwoording

Inleiding Het toenemende belang van kwaliteit Bespreekbaarbeid van kwaliteit Probleemstelling Verantwoording van het onderzoek 1.5 1.5.1 Over de structuur 1.5.2 Over de werkwijze

1

l.l

1

1.2 1.3 1.4

2 4

6 7 7 8

2

Kwaliteit in het informatiesystemen- en softwarevakgebied

11

2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3

Inleiding Definities van kwaliteit in de industriële produktie Literatuur over kwaliteit in de software-industrie Pra.ktijkproblemen: een empirisch onderzoek Het onderzoek Verantwoording van het type onderzoek en de gevolgde werkwijze De praktijk aan het woord: interviewthema's, kernopinies en gespreksonderwerpen Samenvatting en conclusies

11 11

2.5

3 3.1 3.2 3.3

Naar een samenhangend beeld van het ontwikkelen van informatiesystemen

3.3.2 3.3.3 3.3.4 3.4

Inleiding Een kader voor systeemontwikkeling Een samenhangend beeld van ontwikkelaspecten Modelleren en kwaliteit Beheersen en kwaliteit Leren en veranderen en kwaliteit Balanceren en kwaliteit Samenvatting en conclusies

4

Kwaliteitsopvattingen: Wat, Wie en Hoe

4.1 4.2 4.2.1 4.2.2 4.2.3

Inleiding Drie typen kwaliteitsopvattingen: Wat, Wie en Hoe De Produktopvatting De Procesopvatting De Integrale opvatting

3.3.1

15 20 20 21 22 30

33

33 33

36 37 39

41 44 48 49 49

50 50 54

58

4.3 4.3.1 4.3.2 4.3.3 4.4

Objecten van kwaliteit produkten, processen en middelen Objecten van kwaliteit vanuit makers- en afnemersperspectief Objecten van kwaliteit: ordening Objecten van kwaliteit interne en externe attributen Samenvatting en conclusies

61 61 63 64 67

5

Produktkwaliteit

69

Inleiding Wat wordt verstaan onder produktkwaliteit in de literatuur? Definities van produktkwaliteit volgens organisaties voor standaardisatie Het kwaliteitsprofiel volgens (Kaposi en Kitchenham 1987) Een conceptstructuur van produktkwaliteit volgens (Serc-Quint (1992) Beperkingen in het produktkwaliteitsbegrip Een verbeteringsvoorstel: produktdimensies als uitgangspunt De scope van een produkt De toestanden van een produkt De uniekheid van een produkt Produktkarakteristieken geven indicaties voor produktkwaliteitseisen: een toepassing 5.5.1 Kwaliteitseisen volgens (Bemelmans 1991) 5.5.2 Produktdimensies en produktkwaliteitseisen 5.6 Samenvatting en conclusies 5.1 5.2 5.2.1 5.2.2 5.2.3 5.3 5.4 5.4.1 5.4.2 5.4.3 5.5

69 69 70 70 72 74 75 76 78 80 84 84 86 89

6

Proces- en middelenkwaliteit

91

6.1 6.2

Inleiding Wat moet worden verstaan onder processen en middelen van systeemontwikkeling, en wat betekent kwaliteit daarvan ? Processen en proceskwaliteit Middelen en middelenkwaliteit Proces- en middelenkwaliteit vanuit het oogpunt van modelleren Proceskwaliteit vanuit het oogpunt van modelleren Kwaliteit van middelen voor het modelleren Proces- en middelenkwaliteit vanuit het oogpunt van beheersen Proceskwaliteit vanuit het oogpunt van beheersen Middelen voor beheersen Proces- en middelenkwaliteit vanuit het oogpunt van leren en veranderen Proceskwaliteit vanuit het oogpunt van leren en veranderen Middelen voor leren en veranderen Samenvatting en conclusies

91

6.2.1 6.2.2 6.3 6.3.1 6.3.2 6.4 6.4.1 6.4.2 6.5 6.5.1 6.5.2 6.6

91 92 93 95 95

97 99 99 102 104 104 106 108

7

Naar een methode voor het specificeren van kwaliteitseisen

7.1 7.2 7.2.1 7.2.2 7.2.3 7.3 7.3.1 7.3.2 7.4

111 111 111 112 113 115 116 116 118

Inleiding Omgaan met kwaliteitseisen Eérst specificeren dan realiseren Realiseren van kwaliteitseisen Specificeren van kwaliteitseisen Een benaderingswijze voor het specificeren van kwaliteitseisen Benaderingswijzen voor het specificeren van informatiebehoeften De kwaliteitskringloop voor het specificeren van kwaliteitseisen Quality Function Deptoyment (QFD): een methode voor het afleiden van eisen uit afnemerbehoeften 7.5 Van kwaliteitsbehoeften naar kwaliteitseisen 7.5.1 Karakterisering van bedrijfssituaties: Proces-Besturing-Informatie 7.5.2 OriSntatie op de moeilijkheidsgraad van de besturing 7.5.3 Oriëntatie op het te besturen proces 7.6 Samenvatting en conclusies

121 122 124 127 133

8

Nabeschouwing

135

8.1 8.2

Samenvatting en resultaten Aanbevelingen

135 137

Summary

140

Literatuur

143

Index

151

(;urriculum vitae

153

119

1

INLEIDING, PROBLEEMSTELLING EN VERANTWOORDING

1.1 Inleiding Door ontwikkelingen in de markt en het mondiger worden van afnemers is de laatste jaren de roep om kwaliteit van informatiesystemen en software sterker geworden. Marktontwikkelingen hebben betrekking op een sterk expanderende informatiesysteem- en softwareindustrie die onder een toenemende concurrentiedruk· een grote diversiteit aan softwareproduk:ten produceert. Informatiesystemen dringen door in alle geledingen van de samenleving. Voor afnemers variëert de rol van informatiesystemen in hun organisaties van ondersteunend hulpmiddel tot strategisch belangrijk systeem. Voor individuele gebruikers zijn software-applicaties nauwelijks meer weg te denken als noodzakelijk verlengstuk van hun functioneren in de dagelijkse beroepspraktijk. De laatste jaren tekent zich steeds duidelijker af dat afnemers niet langer genoegen nemen met informatiesystemen waarvan de kwaliteit slechts vanuit een beperkt (ontwerpers)oogpunt kan worden aangetoond. Eenzijdige aandacht voor tijdig leveren, aanvaardbare kosten of functionaliteit wordt niet meer geaccepteerd. Kwaliteit dient te voldoen aan de verwachtingen van afnemers binnen de context van een bepaalde bedrijfssituatie. Afnemers wensen garanties voor functionaliteit en kwaliteit in voor hen begrijpelijke termen. Kwaliteit is in de informatiesystemen- en softwarewereld van bijzaak tot hoofdzaak geworden. Een nieuw 'tijdperk' breekt aan dat door vele auteurs wordt aangeduid met het kwaliteitstijdperk, onder andere (Card en Glass 1990, Basili en Musa 1991, Glass 1992). Door (Basili en Musa 1991) worden de voorafgaande decennia als volgt beschreven: Op de jaren '60 wordt teruggekeken als het 'functionele' tijdperk. Voorop stond toentertijd, zowel voor afnemers als makers, de functionaliteit van een informatiesysteem. In de jaren '70 en '80 verschoof de aandacht van functionaliteit van een produkt naar de beheersing van ontwikkelprocessen. Tijdig, planmatig en controleerbaar ontwikkelen werd centraal gesteld. De jaren '80 staan inmiddels bekend als een decenniurr. waarin sterk de nadruk werd gelegd op kosten. Tegenover de sterk dalende prijzen van computersystemen stonden hoge kostenoverschrijdingen van automatiseringsprojecten. De belangstelling voor begrotingsmodellen nam sterk toe. Begin jaren '90 lijkt de informatiesystemen- en software-wereld zich te ontwikkelen van een relatief jong naar een meer volgroeid vakgebied. Functionaliteit, tijdig leveren tegen aanvaardbare kosten worden momenteel gecompleteerd met eisen ten aanzien van kwaliteit Een daadwerkelijke kwaliteitsbeheersing vraagt echter eerst om oplossing van een aantal problemen. Zo is bijvoorbeeld onduidelijk wat makers en afnemers onder kwaliteit verstaan en hoe kwaliteit moet worden bepaald.

1

Inleiding, probleemstelling en verantwoording Dit boek is gericht op het bespreekbaar en hanteerbaar maken van het begrip kwaliteit, toegespitst op informatiesystemen. Centraal daarbij staat de afstemming tussen kwaliteit zoals vereist door afnemers van informatiesystemen en de realiseerbaarheid en beheersbaarheid van kwaliteit zoals gezien door makers van informatiesystemen. Voor het begrip informatiesysteem of software-applicatie bestaan vele verschillende omschrijvingen en definities. In dit boek vatten we een informatiesysteem of software-applicatie op als een geautomatiseerd gegevensverwerkend systemen in een bestuurlijke enlof administratieve omgeving. In dit hoofdstuk geven we in paragraaf 1.2 allereerst een toelichting op het toenemende belang van kwaliteit voor informatiesystemen. Paragraaf 1.3 bespreekt enkele probleemgebieden ten aanzien van kwaliteit. In paragraaf 1.4 wordt de probleemstelling beschreven. Paragraaf 1.5 sluit dit hoofdstuk af met een verantwoording van het onderzoek.

1.2 Het toenemende belang van kwallteit In tegenstelling tot een aantal jaren geleden is kwaliteit voor zowel afnemers als makers van informatiesystemen relevant. Het toenemende belang van kwaliteit kan vanuit drie invalshoeken worden gel:llustreerd:

het succes van ondernemingen (de afnemers) de concurrentiepositie binnen de S()ftware-industrie (de makers) de afstemming tussen afnemers en makers van informatiesystemen Het succes van ondernemingen 'Organisaties willen geen dozen maar oplossingen', aldus een vooraanstaand manager van een groot bankbedrijf in Nederland. Deze uitspraak deed onlangs nog al wat stof opwaaien in de discussie tussen afnemers en makers van informatiesystemen. Hoewel informatiesystemen in toenemende mate van groot belang zijn voor het succes van organisaties, worden beloften niet altijd waargemaakt en wordt niet steeds voldaan aan hooggestemde verwachtingen. Duidelijk is dat tal van (informatie)wensen van afnemers vooralsnog onbeantwoord zijn gebleven, ondanks de grote inspanningen in de software-industrie, zowel op het gebied van de ontwikkeling van complete standaardoplossingen als op het gebied van de ontwikkeling van unieke informatiesystemen. Afnemers vragen in deze tijd om een meerwaarde die gemakshalve kwaliteit wordt genoemd. Vaak wordt daarmee bedoeld dat informatiesystemen 'naadloos' worden ingepast in de werkwijzen en de procedures van een organisatie. Alleen dan kan daadwerkelijk een bijdrage worden geleverd aan het verwezenlijken van de doelstellingen van een onderneming. Uiteraard is het bepalen en realiseren van de gewenste kwaliteit een verantwoordelijkeid van zowel de makers als van de afnemers van informatiesystemen.

2

Hoofdstuk 1

De concurrentiepositie binnen de software-industrie Gezien de verhoogde concurrentie tussen software-bedrijven, nog versterkt door de toenemende internationalisering en economische liberalisering (onder meer Europa 1992), wordt kwaliteit van informatiesystemen een halszaak. Makers en leveranciers van informatiesystemen moeten aantoonbare kwaliteit leveren en dienen duidelijk te maken aan afnemers op welke wijze zij kwaliteit van informatiesystemen bewerkstelligen. De tot stand koming van een algemene ISO (International Standards Organization)-standaard voor kwaliteit voor de industrie in 1987 heeft inmiddels geleid tot het ontstaan van soortgelijke standaards voor de software-industrie. Genoemd kunnen worden de TickiT-standaards in Engeland (Tick:IT 1991), en de standaards van de lnformation Technology Research and Standardization Center (INSTAC) in Japan (Azuma 1991). Daarnaast is ook de algemene ISO-standaard vertaald en toegesneden op de informatiesystemen- en software-industrie (ISO 9000-3 1991). Veel software-huizen werken momenteel aan de opzet van kwaliteitssystemen c.q. de ontwikkeling van stelsels van voorschriften en richtlijnen voor kwaliteitszorg en -bewaking. Door certificatie na te streven van kwaliteitssystemen wordt getracht het vertrouwen van afnemers te winnen en meer grip te krijgen op de kwaliteit van ontwikkelprocessen. De afstemming tussen afnemers en makers van informatiesystemen Mnemers en makers dienen overeenstemming te bereiken over gewenste maar tevens haalbare kwaliteit Overeenstemming is alleen mogelijk wanneer afnemers en makers kwaliteitseisen ten aanzien van informatiesystemen in bespreekbare termen uitdrukken. Onderscheid tussen subjectieve waarderingen en objectieve (kwantificeerbare) kwaliteitseisen is daarbij een voorwaarde. Makers worden verondersteld te kunnen voldoen aan door afnemers gestelde kwaliteitseisen. Tevens wordt van makers in toenemende mate verwacht dat zij naast technische aspecten ook rekening kunnen houden met aspecten van bijvoorbeeld organisatiekundige, sociotechnische en economische aard (Avison en Wood-Harper 1990). Het moge duidelijk zijn dat de werelden van makers en afnemers op een aantal punten wezenlijk verschillen. Mstemming tussen afnemers en makers met betrekking tot kwaliteit vraagt om "balanceren" tussen de ene en de andere wereld. Voorkomen moet worden dat kwaliteit buiten het gezichtsveld valt van een van de betrokken partijen. In toenemende mate wordt in literatuur en praktijk aandacht besteed aan het maken van vertaalslagen tussen kwaliteitseisen van afnemers en van makers (Delen, Kouwenhoven en Rijsenbrij 1991, Serc-Quint 1992).

3

Inleiding, probleemstelling en verantwoording

1.3

Bespreekbaarbeid van kwaliteit

De voorgaande paragraaf heeft geschetst dat sinds enkele jaren zowel door afnemers als door makers van infonnatiesystemen kwaliteit voorop wordt gesteld. De bespreekbaarbeid van kwaliteit laat echter op vele punten te wensen over. Uit litera~ur en praktijk komen onder andere de volgende probleemgebieden naar voren: -

men is onvoldoende bekend met de multi-dimensionaliteit van het begrip kwaliteit men weet moeilijk om te gaan met subjectieve begrippen ten aanzien van kwaliteit open vraag is hoe te balanceren bij het bewerkstelligen van kwaliteit rol en betekenis van methoden en geautomatiseerde gereedschappen bij het bewerkstelligen van kwaliteit zijn vooralsnog vaag en onduidelijk

We bespreken deze problemen kort in het navolgende. Probleem 1:

de multi-dimensionaliteit van het begrip kwaliteit

Zowel de wereld van de maker als de wereld van de afnemer kunnen naar tal van invalshoeken worden beschreven. Als gevolg daarvan zijn verschillende defmities ontstaan van kwaliteit. Veel problemen op het gebied van kwaliteit en kwaliteitsbeheersing worden veroorzaakt doordat betrokken partijen over en weer niet bekend zijn met de verschillen in elkaars definities (Garvin 1984). Probleem 2:

de subjectiviteit in het begrip kwaliteit

Bij kwaliteit is het onderscheid nuttig tussen enerzijds kwantitatief meetbare (objectieve) aspecten van kwaliteit en anderzijds de subjectieve waarderingsaspecten van kwaliteit (Kaposi en Kitchenham 1987). Sommigen maken dit onderscheid niet maar trachten door verfijning van kwaliteitseisen in kwantitatief meetbare attributen alle subjectiviteit uit te bannen. Vervolgens wordt getracht de gespecificeerde kwaliteitsattributen te realiseren door allerlei ontwerpmaatregelen en door het toepassen van stringente meetvoorschriften. Veelal is de vraag is gerechtvaardigd in hoeverre hier sprake is van een 'schijnbaar' objectiveringsproces. ook gezien de subjectieve beslissingen die bij de genoemde werkwijze worden genomen door de makers. Voorbeelden van dergelijke beslissingen zijn: de keuze uit de vele mogelijkheden van opsplitsing van kwaliteitseisen, de keuze uit de vele onderlinge relaties tussen kwaliteitsattributen, de keuze tussen de te nemen maatregelen etcetera. Probleem 3:

balanceren bij het bewerkstelligen van kwaliteit

Kwaliteitseisen, maatregelen om die kwaliteitseisen te realiseren en meetvoorschriften om kwaliteit te evalueren beïnvloeden elkaar onderling. Eenzijdig de nadruk leggen op een bepaalde kwaliteitseis, een te grote gerichtheid op een bepaald type maatregel of een teveel aan vertrouwen in een bepaald meetvoorschrift kan gevolgen hebben voor zowel maker als afnemer. Specificeren en realiseren van kwaliteit vereisen telkens afwegingen, zowel tussen als binnen de werelden van de maker en de afnemer, zie onder andere (Strausz 1983). Dit

4

Hoofdstuk 1 maken van afwegingen bij het ontwikkelen van wonnatiesystemen wordt balanceren genoemd. Binnen de wereld van de afnemer heeft balanceren onder meer betrekking op de prioriteitenstelling van kwaliteitseisen vanuit verschillende perspectieven (beheer, gebruik, opdrachtverstrekldng etcetera) onder randvoorwaarden ten aanzien van kosten en levertijd. Binnen de wereld van de maker heeft balanceren betrekking op het maken van afwegingen tussen de mogelijke maatregelen om kwaliteit te bewerkstelligen en de mogelijke metingen om kwaliteit aantoonbaar te maken. Ook hier binnen kosten- en levertijdcondities. Mwegingen tussen de werelden van afnemers en makers zijn onder andere afwegingen tussen wat gevraagd wordt enerzijds en wat mogelijk c.q. betaalbaar is anderzijds. Telkens dient door afnemers en makers een balans te worden gevonden tussen gewenste, maakbare en haalbare kwaliteit. Hierover bestaat vooralsnog geen theoretisch sluitend raamwerk (Basili en Selby 1991). De plaats en betekenis van balanceren wordt uitvoerig beschreven in hoofdstuk 3. Probleem 4:

de rol en betekenis van methoden en geautomatiseerde gereedschappen voor het bewerkstelligen van kwaliteit

Methoden en geautomatiseerde gereedschappen zijn niet weg te denken bij het ontwikkelen van infonnatiesystemen. Zonder deze hulpmiddelen is er geen sprake van een volwassen vakgebied (Nonnan en Forte 1992). Een en ander blijkt ook uit een empirisch onderzoek naar het belang van methoden en gereedschappen dat voor het Software Engineering Research Center (Serc) werd uitgevoerd (Trienekens en van Reeken 1992). De resultaten van dit onderzoek worden uitvoerig beschreven in hoofdstuk twee. Op grond van praktijken literatuuronderzoek zijn belangrijke conclusies met betrekking tot het belang van methoden en gereedschappen: methoden en gereedschappen zijn van groot belang voor de beheersbaarheid en de controleerbaarheid van het ontwikkelwerk; methoden en gereedschappen ondersteunen nauwelijks het omgaan met kwaliteitseisen. Methoden en gereedschappen blijken eenzijdig gericht te zijn op het specificeren en realiseren van de functionaliteit van een infonnatiesysteem (Bemelmans 1990, Basili 1993). De afgelopen jaren zijn tal van nieuwe methoden en gereedschappen toegevoegd aan het al zeer uitgebreide arsenaal. Vrijwel elke (nieuwe) methode of elk (nieuw) gereedschap pretendeert een kwaliteitsverbetering te bewerkstelligen, terwijl meestal slechts één bepaald aspect of één bepaald traject van systeemontwikkeling wordt afgedekt. Verder wordt kwaliteit veelal in globale tenuen uitgedrukt waardoor niet altijd duidelijk is wat ennee wordt ~edoeld (Card en Glass 1990). ·

5

Inleiding, probleemstelling en verantwoording

1.4

Probleemstelling

Uit de voorgaande paragrafen moge duidelijk zijn geworden dat het belang van kwaliteit bijna unaniem wordt onderschreven. Probleem is echter dat noch in theorie noch in praktijk voldoende aanzetten bestaan om kwaliteit te "operationaliseren". Eerste knelpunt is al dat iedereen iets anders verstaat onder kwaliteit Eenduidigheid van definities en omschrijvingen bestaat derhalve nauwelijks. Zo men het al eens is over definities, is het volgende knelpunt kwaliteit van wat ? Daarna volgen successievelijk vragen over hoe kwaliteit te realiseren, hoe te meten, hoe te handhaven etcetera. Kortom: meer vragen dan oplossingen. Dit brengt ons tot de volgende vraagstellingen van dit boek: welk ordeningskader is geschikt om het begrip kwaliteit te operationaliseren ? Dit ordeningskader moet zijn gebaseerd op valide theoretische concepten en moet praktisch bruikbaar zijn. Op welke wijze kan het omgaan met kwaliteit in het informatiesystemen- en softwarevakgebied worden verbeterd ? Uit voorgaande vraagstelling is tevens het doel van dit boek af te leiden. Doel is een bijdrage te leveren aan zowel de "leer" (de theorie) als de "kunde" ten aanzien van kwaliteit en kwaliteitsbeheersing bij informatiesystemen.

De afbakening van het onderzoek lichten we toe aan de hand van de fasen, de aspecten en de toepassingsgebieden van informatiesysteemontwikkeling. De fasen van informatiesysteemontwikkeling Systeemontwikkeling wordt meestal opgedeeld in diverse fasen. Onderscheiden worden de fasen informatieplanning, defmitiestudie, analyse en ontwerp, coderen en testen, invoeren, onderhoud. Kwaliteit is van belang voor de gehele lifecycle van informatiesysteemontwikkeling. In dit onderzoek richten we ons zowel vanuit het perspectief van de afnemer als van de maker op de gehele lifecycle, met uitzondering van de fase informatieplanning. Die laatstgenoemde fase laten we buiten beschouwing omdat daarin niet de ontwikkeling van één systeem centraal staat, maar de opzet van een "bestemmingsplan" voor een veelheid aan systemen.

De aspecten van informatiesysteemontwikkeling Ontwikkelen van informatiesystemen kent verschillende aspecten (Bemelmans 1991). Naast modelleren (lees: specificeren en realiseren) wordt onderscheid gemaakt in beheersen, balanceren, leren en veranderen. Modelleren en beheersen en de rol en betekenis van kwaliteit nemen in dit boek een belangrijke plaats in. Het omgaan met kwaliteit wordt uiteindelijk toegespitst op het specificeren en realiseren (het modelleren) van kwaliteitseisen. Het aspect balanceren speelt daarbij zoals zal blijken, een belangrijke rol. "Leren" en "veranderen" spelen zijdelings een rol in dit boek. De reden daarvan is niet dat "leren" en "veranderen" minder belangrijk zouden zijn, integendeel. Maar beide aspecten raken meer

6

Hoofdstuk 1

de organisatiekundige dan de informatiekundige problematiek. Wij willen ons vooralsnog concentreren op de informatiekundige problematiek van informatiesysteemontwikkeling. De toepassingsgebieden van informatiesysteemontwikkeling Gezien het inventariserende en ordenende karakter van met name de eerste vier hoofdstukken wordt in dit onderzoek in het begin niet uitgegaan van een bepaald type of van een bepaalde typologie van informatiesystemen of systeemontwikkeling. Wel staan in met name de hoofdstukken 5. 6 en 7 het type "bestuurlijke informatiesystemen" centraal bij het ontwikkelen van de "kunde" ten aanzien van het omgaan met kwaliteit In dit boek wordt die kunde toegespitst op een methode voor het specificeren van kwaliteitseisen. Deze methode is bestemd voor informatiesysteemontwikkelaars die uitgaan van individuele wensen en behoeften van afnemers.

1.5

Verantwoording van het onderzoek

Gezien de vele onbeantwoorde vragen en de grote onduidelijkheden rond kwaliteit is in dit boek na een verkennende fase. eerst de nadruk gelegd op een inventarisatie en ordening van kwaliteitsbegrippen en kwaliteitsindelingen. Dit is vervolgens uitgangspunt geweest voor een theoretisch verankerd ordeningskader voor kwaliteit. We beschrijven achtereenvolgens kort de structuur en de gevolgde welkwijze in dit onderzoek.

1.5.1 Over de structuur Vetkenning (hoofdstukken I en 2) In het vetkennende deel wordt op basis van literatuuronderzoek een beeld geschetst van de actuele problematiek rond kwaliteit binnen informatiesysteemontwikkeling. De beschrijving van de huidige stand van zaken. in het bijzonder problemen en knelpunten wordt aangevuld met de resultaten van een empirisch onderzoek (hoofdstuk 2).

Ordening (hoofdstukken 3 en 4) De resultaten van zowel de literatuurstudie als het empirisch onderzoek nodigen uit tot een eerste ordening. Hoofdstuk 3 beschrijft een ordening van relevante systeemontwikkelbegrippen. In relatie daarmee wordt in hoofdstuk 4 een ordening van de verschillende kwaliteitsopvattingen en -indelingen gegeven.

Aanzetten tot verbetering (hoofdstukken 5, 6 en 7) In de hoofdstukken 5, 6 en 7 worden aanzetten ontwikkeld voor de operationalisering van het begrip kwaliteit. Op grond van de tekortkomingen en onduidelijkheden die aan het licht

7

Inleiding, probleemstelling en verantwoording zijn gekomen in het ordenende deel, worden in de eerste paragrafen van· genoemde hoofdstukken theoretische en praktische kaders beschreven voor respectievelijk produkt-, procesen middelenkwaliteit Daarnaast wordt een methode ontwikkeld voor het specificeren van kwaliteitseisen.

1.5.2 Over de werkwijze Verkenning (hoofdstukken 1 en 2) Naast literatuurstudie die ten grondslag heeft gelegen aan de gehele studie, werd in het begin van deze studie een empirisch onderzoek uitgevoerd naar het belang van methoden en gereedschappen bij het ontwikkelen van informatiesystemen (Trienekens en van Reeken 1992, Stobart et al 1993). De vele verschillende publicaties over knelpunten en problemen in de praktijk waren aanleiding om zelf in de praktijk te onderzoeken wat' er daadwerkelijk aan de hand is. Er werd gekozen voor een kwalitatieve studie door middel van het afnemen van diepte-interviews bij een zorgvuldig geselecteerde groep praktijkmensen met vele jaren systeemervaring. Opvattingen, bestaande onduidelijkheden en actuele behooften bleken op een aantal punten duidelijk te verschillen met opvattingen in de literatuur over het methodisch ontwikkelen van informatiesystemen. Met name noemen we hier de opvatting van praktijkmensen dat nieuwe concepten en methoden alleen worden geaccepteerd wanneer deze kunnen worden ingepast in bestaande werkwijzen. Ook gaf men te kennen dat men meer vertrouwen had in verbetering op deelgebieden van het ontwikkelen van informatiesystemen dan aan geheel nieuwe benaderingswijzen en technieken. De resultaten van het empirische onderzoek zijn mede bepalend geweest voor de probleemstelling en de gevolgde werkwijze. Ordening (hoofdstukken 3 en 4) Op grond van de resultaten van de verkennende hoofdstukken 1 en 2 is in. hoofdstuk 3 een

eerste ordening van relevante ontwikkelaspecten ontwikkeld. De essentie en de samenhang van de verschillende ontwikkelaspecten worden daarin uiteengezet. Dit is vervolgens uitgangspunt geweest voor de ontwikkeling van een ordeningskader voor kwaliteitsbegrippen en -indelingen. Aanzetten tot verbetering (hoofdstukken 5, 6 en 7) Hoofdstuk 5 bespreekt eerst kort drie verschillende opvattingen over produktkwaliteit in de informatiesystemenliteratuur. Na een bespreking van de beperkingen van deze opvattingen wordt een verbeteringsvoorstel gedaan. Centraal staat daarin het karakteriseren van een informatiesysteem of softwareprodukt op drie dimensies, te weten de dimensie van de scope, de toestanden en de uniekheid van een softwareprodukt Aan de hand van een toepassing wordt vervolgens geûlustreerd op welke wijze de drie produktdimensies samenhangen met kwaliteitseisen.

8

Hoofdstuk 1 Hoofdstuk 6 gaat in op de betekenis van proces- en middelenkwaliteit. Het centrale thema in dit hoofdstuk is dat eerst duidelijk moet worden met welke processen men bij informatiesysteemontwikkeling te maken heeft en welke middelen in die processen kunnen worden ingezet. Eerst dan kan kwaliteit van processen en middelen worden bepaald.

In hoofdstuk 7 wordt een methode voor het specificeren van kwaliteitseisen ontwikkeld. Een van de uitgangspunten voor die methode is het karakteriseren van een informatiesysteem op drie produktdimensies. Echter, om een informatiesysteem te kunnen karakteriseren is inzicht nodig in de bedrijfssituaties waar behoefte bestaat aan dat systeem. Het PBIparadigma (Proces-Besturing-Informatie) wordt gebruikt om dat inzicht te verkrijgen. Daarnaast wordt voor de beschrijving van de methode gebruik gemaakt van de methode Quality Function Deployment die de laatste jaren in de industri15le sector sterk in de belangstelling staat (Hauser en Clausing 1988). Hoofdstuk 8 sluit dit boek af met conclusies en aanbevelingen.

9

2

KWALITEIT IN HET SOFTWAREVAKGEBIED

2.1

Inleiding

INFORMATIESYSTEMEN-

EN

Kwaliteit evolueert in de software-industrie van algemeen 'buzz-word' tot serieus aandachtsgebied. Zoals het geval met elke snelle ontwikkeling binnen een vakdiscipline, kent kwaliteit en de beheersing daarvan in de software-industrie een overdaad aan definities en opvattingen. De gevolgen laten zich raden: spraakverwarring en misverstanden bij het maken van afspraken over kwaliteit, onduidelijkheid bij software-ontwikkelaars over hoe met kwaliteit om te gaan, te hoog gespannen verwachtingen bij afnemers en vaak grote onvrede achteraf bij het opleveren van systemen. Om deze problemen te voorkomen is eerst een goed inzicht nodig in het vakgebied van de informatiesysteemontwikkeling. Vanuit een bedrijfskundig perspectief bezien dient dit inzicht te zijn gebaseerd op zowel literatuur- als praktijkonderzoek. Vervolgens kan gericht worden gewerkt aan de plaats en betekenis van het begrip kwaliteit bij het ontwikkelen van informatiesystemen en kan worden getracht de hanteerbaarbeid van het begrip kwaliteit te verbeteren.

In andere vakgebieden hebben zich al eerder soortgelijke ontwikkelingen voltrokken. In de produktie-industrie is door (Garvin 1984) ordenend werk verricht op met name het gebied van kwaliteitsdefinities. Het referentiekader dat door hem wordt beschreven kan onder meer worden gebruikt om accenten, leemtes en trends te identificeren in de vele verschillende benaderingen van kwaliteit. In dit hoofdstuk geven we in paragraaf 2.2 allereerst een overzicht van de verschillende kwaliteitsdefinities volgens Garvin. Vervolgens beschrijven we kort in paragraaf 2.3 de meest bekende benaderingen van kwaliteit in de literatuur van het informatiesystemen- en softwarevakgebied. We merken op dat het in dit hoofdstuk nog niet gaat om een diepgaande analyse of gedetailleerde beschrijving. Doelstelling is hier een eerste beeldvorming van de wijze waarop met kwaliteit wordt omgegaan in de software-industrie. Door het definitiestelsel van Garvin als referentiekader te gebruiken komen enkele leemtes aan het licht van het omgaan met kwaliteit. Paragraaf 2.4 bespreekt de resultaten van een praktijkonderzoek naar de belangrijkste problemen en knelpunten van informatiesysteemontwikkeling in de praktijk. De resultaten van dit onderzoek worden in dit boek op tweëerlei wijze gebruikt. Enerzijds vormen zij de uitgangspunten voor het ordenende werk in dit boek, anderzijds fungeren zij als randvoorwaarden bij het verbeteren van de hanteerbaarheid van het begrip kwaliteit (met name in de hoofdstukken 5 en 7). Paragraaf 2.5 sluit dit hoofdstuk af met conclusies.

2.2

Definities van kwaliteit in de industriële produktie

Met het begrip kwaliteit wordt in de dagelijkse praktijk gemakkelijk omgesprongen. Vaak gaat het daarbij om een individuele mening over de uitmuntendheid van een bepaald voorwerp of object. Stelt men vervolgens de vraag wat kwaliteit dan precies inhoudt dan ervaart men vaak het onvermogen om dat toe te lichten. Kwaliteit schijnt immers eenvoudig te herkennen, men 11

Kwaliteit in het informatiesystemen- en softwaregebied ziet het of men ziet het niet, het is altijd meer dan de som van een aantal eigenschappen. Echter, in een industriêle en zakelijke context ontkomt men er niet aan om eigenschappen te definiêren die kwaliteit bepalen, is het noodzakelijk om maatregelen te nemen en om metingen te verrichten om kwaliteit te bewerkstelligen. Dit is een complex proces waarbij zorgvuldige afwegingen dienen te worden gemaakt tussen onder andere objectieve en subjectieve wensen en eisen, tussen soorten te nemen maatregelen en tussen verschillende te hanteren meet- en toetsvoorschriften. De complexiteit wordt vergroot doordat verschillende betrokken partijen vanuit verschillende invalshoeken van verschillende kwaliteitsbegrippen uitgaan. Door Garvin (1984) zijn op grond van onderzoek in de produktie-industrie verschillende soorten kwaliteitsdeftnities beschreven en geordend. Mede ten gevolge van de toenemende industrialisatie in het softwarevakgebied wordt meer en meer aan deze ordening gerefereerd. De vijf soorten defm.ities van kwaliteit die men volgens Garvin kan onderscheiden, zijn respectievelijk: transcendent based definities product based definities user based defm.ities manufacturing based definities value based definities We bespreken deze soorten defm.ities kort in het navolgende. De transcendent based defm.ities Kwaliteit is volgens de transcendent based defm.ities universeel herkenbaar. Hoewel kwaliteit zich niet laat analyseren en bemeten wordt kwaliteit afgespiegeld als een relatief eenvoudige eigenschap van een voorwerp of een systeem. Voorbeelden kunnen worden ontleend aan de filosofie (bijvoorbeeld de esthetiek of schoonheidsleer) waar kwaliteit van voorwerpen of systemen blijkt uit onder andere de affectieve gevoelens die worden opgeroepen door vorm, kleur, smaak en geluid. Het meest opvallende in deze opvatting is dat kwaliteit niet ter discussie staat; kwaliteit is immers absoluut, men ervaart het of niet, men voelt het aan of niet. De transcendent based defm.ities worden met name gebruikt (en misbruikt) bij het geven van waarde-oordelen over allerlei soorten objecten; over individuele voorwerpen en personen tot sociale en culturele systemen. Een bezwaar van deze kwaliteitsopvatting is het esoterische karakter ervan. Kwaliteit van objecten kan alleen worden herkend in de vergelijkende sfeer. Het komt er op neer dat men een 'ingewijde' dient te zijn met betrekking tot een bepaald soort voorwerpen, systemen of stelsels. Hoewel niet operationeel berneetbaar kan deze soort defm.ities niet worden verwaarloosd. Een transcendente uitspraak kan vaak een gevoel over kwaliteit uitdrukken dat aanknopingspunten biedt voor het vervolgens identificeren van concrete eigenschappen. ·

12

Hoofdstuk 2 De user based defmities In deze definities wordt kwaliteit beschouwd als datgene waardoor een produkt of voorwerp voldoet aan individuele wensen en behoeften van gebmikers. Met andere woorden kwaliteit is wat de gebmiker ervan vindt: 'quality is fitness for use' (Juran 1979). Kwaliteit is volgens deze opvatting grotendeels subjectief en alleen op 'kwalititatieve' wijze te meten en te toetsen. De user based defmities hebben betrekking op die eigenschappen van produkten die voor de gebmikers van doorslaggevend belang zijn. Producenten die deze defmities hanteren richten zich op een geschikte combinatie van produktkenmerken die voor een klant kwaliteit betekenen. Een probleem voor producenten is om de individuele behoeften en voorkeuren van gebruikers zodanig te verenigen dat wordt voldaan aan kwaliteit voor een bepaalde categorie gebmikers. Een ander probleem bij het gebmik van deze defmities is om vast te stellen of een gebmiker 'slechts' tevreden is of dat 'echt' kwaliteit wordt toegekend aan een produkt. Echte kwaliteit heeft dan te maken metextra's waardoor gebmikers enthousiast worden, geïnspireerd raken, etcetera. De product based defmities Volgens de product based definities wordt kwaliteit bepaald door een aantal eenduidig gedefinieerde kenmerken van een produkt. Deze kenmerken zijn op objectieve wijze vast te stellen door meting en toetsing. Het kwaliteitsbegrip dient volgens deze opvatting op de eerste plaats gebaseerd te zijn op de binnen een discipline geldende kwaliteitsnormen. Een consequentie van deze opvatting is dat verschillen in kwaliteit van produkten met name terug te voeren zijn op verschillen in aantallen kenmerken van een produkt c.q. meetwaarden. De vraag is gerechtvaardigd of een produkt met meer kenmerken ook meer kwaliteit heeft. zeker gezien de overweging dat meer kenmerken vrijwel altijd hogere kosten betekenen. Een ander belangrijk probleem in deze opvatting is om te bepalen in welke mate en op welke wijze de kenmerken elkaar onderling (en dus de kwaliteit in totaal) beinvloeden. Bekend is de situatie waarin het verbeteren van het ene kwaliteitskenmerk verslechtering van andere kenmerken tot gevolg heeft De manufacturing based defmities Volgens deze definities heeft kwaliteit betrekking op het voldoen van produkten aan vooraf vastgestelde specificaties: 'conformance to requirements' (Crosby 1979). Deze definities stellen dat kwaliteit met name wordt bereikt door metingen te verrichten aan (tussen)produkten tijdens de ontwikkelprocessen. Kwaliteit bewerkstelligen is volgens deze opvatting sterk gebaseerd op het 'in een keer goed doen' van ontwikkelwerkzaamheden. In feite gaat het hier om een 'process' based defmitie van kwaliteit. In tegenstelling tot de vraag- of gebmikskant die centraal staat in de user based definities wordt in de manufacturing based defmities uitgegaan van de aanbod- of de produktiezijde. Kwaliteit bewerkstelligen is volgens de manufacturing based defmities primair gericht op het registreren en elimineren van afwijkingen en fouten in het produktieproces. Centraal staan ontwikkelprocedures voor ontwerpers en managementprocedures om kwaliteit te plannen en

13

Kwaliteit in het informatiesystemen- en softwaregebied te controleren. In de prakûjk heeft dit onder andere geleid tot een nogal statistische kwaliteitsbeheersing. De noodzaak van het maken van afwegingen tussen de opbrengsten enerzijds en de kosten van kwaliteitsbeheersing anderzijds wordt in zo'n aanpak vaak onvoldoende onderkend.

De value based defmities Deze defmities stellen dat kwaliteit niet absoluut is maar moet worden bekeken in verhouding tot tijd, kosten en inspanning. De value based definities benadrukken de noodzaak van het maken van afwegingen. In de toelichtingen op de voorgaande defmities blijkt dat het maken van afwegingen in ieder van de soorten definities een rol speelt. De value based definities benadrukken het meest complexe aspect van het omgaan met kwaliteit. Het maken van afwegingen heeft namelijk vaak betrekking op verschillende soorten waardeoordelen, qua functionaliteit, performance, tijd en kosten, die op geheel verschillende manieren kunnen worden gemeten en getoetst. Ook gelden in deze soort definities complexe afwegingsprocessen tussen verschillende groepen betrokkenen, bijvoorbeeld opdrachtgevers, klanten, ontwerpers en producenten. Conclusies Duidelijk is dat per soort kwaliteitsdefmitie de inhoud en de scope wisselen. Bijvoorbeeld de user based definities richten zich met name op de vraagzijde van het voortbengingsproces, terwijl de product based en de manufacturing definities zich voornamelijk beperken tot de aanbodzijde. De value based defmities zijn voor zowel vraag- als aanbodzijde van toepassing. Dit geldt ook voor de transcendent based defmities. Uit het voorgaande blijkt dat de mate van absoluutheid en de mate van objectiviteit verschillen per soort definitie, waarbij absoluutheid en objectiviteit niet als equivalente begrippen mogen worden opgevat. Bijvoorbeeld in de transcendent based defmities is kwaliteit absoluut (in filosofische zin), maar uiterst subjectief en niet toetsbaar. Daarentegen is kwaliteit volgens de value based opvatting nooit iets absoluuts; altijd behoren afwegingen te worden gemaakt tussen bijvoorbeeld de meningen van verschillende betrokkenen over verschillende soorten kwaliteitskenmerken in relatie tot tijd- en kostenaspecten. Het feit dat wordt gewerkt met verschillende waarden- en normenstelsels leidt tot een beperkte objectieve toetsbaarbeid van kwaliteit. Ook volgens de user based defmities is kwaliteit nooit absoluut, inaar afhankelijk van de behoeften en voorkeuren van individuele gebruikers. Ooidelijk is dat ih deze opvatting per gebruiker(sgroep) kwaliteit slechts beperkt kwantitatief is te toetsen. In de product based defmities is kwaliteit absoluut; namelijk de "optelsom" van een verzameling objectieve kwaliteitskenmerken. Kwaliteit dient volgens deze opvatting altijd kwantitatief toetsbaar te zijn. Dit geldt ook voor de manufacturing based defmities. Garvin's kader geeft een ordening van verschillende kwaliteitsdefmities. In de volgende paragraaf bespreken we tegen de achtergond van dit kader enkele bekende kwaliteitsopvattingen uit de literatuur van het informatiesystemen- en softwarevakgebied.

14

Hoofdstuk 2

2.3

Literatuur over kwaliteit in de software-industrie

Zoals eerder venneld is in de laatste jaren in de software-industrie het begrip kwaliteit geëvolueerd tot een serieus aandachtsgebied. Sinds de zeventiger jaren heeft in benaderingen van kwaliteit het accent gelegen op de kwaliteit van een softwareprodukt (uitgedrukt in eigenschappen van dat produkt). Echter, recent zijn benaderingen van kwaliteit ontstaan en verder uitgewerkt waarbinnen het accent ligt op het wijze waarop kwaliteit kan worden bewerkstelligd. In het navolgende worden de belangrijkste benaderingen in de infonnatiesystemenwereld gepositioneerd tegen de achtergrond van het definitiestelsel van Garvin. Als vertegenwoordigers van kwaliteitsbenaderingen van 'het eerste uur' kunnen in de software-industrie respectievelijk Boehm (1978) en Cavano en McCall (1978) worden beschouwd. Van meer recente signatuur zijn de kwaliteitsbenaderingen volgens ISO 9001 en Total Quality Management (TQM) (Oakland 1989).

De kwaliteitsbenadering volgens (Boehm 1978, Cavano en McCall1978) In deze benadering van kwaliteit wordt kwaliteit uitgedrukt in een verzameling kwaliteitskenmerken. De grondleggers van deze benadering zijn (Boehm et al 1978) en (Cavano en McCall 1978). We gaan bij de bespreking van deze opvattingen niet in op de precieze betekenis van de afzonderlijke kwaliteitskenmerken maar beperken ons tot een beschrijving van de structuur van de verzameling kwaliteitskenmerken.

Figuur 2.1 Kwaliteit volgens (Boehm et al 1978)

15

Kwaliteit in het informatiesystemen- en softwaregebied kwaliteit volgens Boehm Wellicht het meest bekend op het gebied van kwaliteit in de software-industrie is de structuur van kwaliteitskenmerken volgens Boehm, zie Figuur 2.1. De "boom van Boehm" geldt in het vakgebied van de software engineering als een eerste poging om het begrip kwaliteit te operationaliseren. De structuur wordt bepaald door aggregaties en specialisaties van kwaliteitskenmerken. Uitgangspunt zijn de aggregaties 'overdraagbaarheid', 'huidige nuttigheid' en 'onderhoudbaarheid'. Uit deze drie 'hoofd'kenmerken worden vervolgens langs hiërarchische weg kenmerken en deelkenmerken van een softwareprodukt afgeleid. kwaliteit volgens Cavano en McCall Cavano en McCall maken onderscheid in kwaliteitskenmerken vanuit drie· invalshoeken, te weten 'produkt gebruik' ofwel de wijze waarop een softwareprodukt functioneert, 'produkt revisie' ofwel de wijze waarop een softwareprodukt kan worden aangepast, en 'produkt transitie' ofwel de wijze waarop een softwareprodukt kan overgaan in een volgende generatie. Binnen elk van de genoemde invalshoeken worden vervolgens kwaliteitskenmerken van software gedefmieerd, zie Figuur 2.2.

produl<:t gebruiK juistheld betrouwballrheld brUikba!ll'held

éfflelênt Ie

Integriteit

Figuur 2.2 Kwaliteit volgens (Cavano en McCall1978) In deze figuur is niet gekozen voor het hiërarchisch afleiden van kenmerken uit aggregaties van kwaliteitskenmerken. Uitgangspunt is de levenscyclus van een softwareprodukt. Afhankelijk van de fase waarin een produkt zich bevindt, of die een produkt dient te doorlopen, zijn verschillende kwaliteitskenmerken relevant. Uit de figuur blijkt dat Cavano en McCall hebben gepoogd de kwaliteitskenmerken in voor gebruikers begrijpelijke taal te formuleren.

16

Hoofdstuk 2 Opgemerkt moet worden dat de kwaliteitsbenadering van Cavano en McCall verder reikt dan figuur 2.2. Bijvoorbeeld onderscheiden Cavano en McCall naast de kwaliteitskenmerken in de figuur een tweede (onderliggende) niveau van kwaliteitskenmerken, criteria genoemd. Aan de hand van een matrix worden de relaties aangegeven tussen de kenmerken van de verschillende niveau's. Voor de kwaliteitscriteria worden indicatoren beschreven waaraan concrete (lees: objectieve) metingen kunnen worden verricht (Vincent et al 1988). De beide benaderingen van Boehm en van Cavano en McCall richten zich op het ontwerpen ofwel op de technische realisatie van kenmerken in een softwareprodukt. Kwaliteit wordt afhankelijk gesteld van het aantal kenmerken dat een produkt meekrijgt. Doel is om kwaliteit objectief en kwantitatief meetbaar te maken. Op grond van bovenstaande beschrijvingen moge duidelijk zijn dat produktkwaliteit in de software-industrie als een complex en rijk geschakeerd fenomeen wordt beschouwd. De kwaliteitsbenaderingen volgens ISO 9000 en TQM De IS0-9000- en de TQM-benaderingen van kwaliteit richten zich respectievelijk op de structurering en op de verbetering van het ontwikkelwerk zelf. Door ISO 9000 worden stelsels van internationale standaards voorgeschreven voor het opstellen van procedures voor de beheersing en de uitvoering van het ontwikkelwerk. TQM is gericht op een integrale benadering van kwaliteitszorg en kwaliteitsverbetering. Naast produkt- en procesaspecten spelen menskundige aspecten een belangriJke rol. Voor wat betreft dit laatste noemen we met name de samenwerking in groepsverband ('teamwork'). We lichten deze benaderingen achtereenvolgens kort toe. kwaliteit volgens (ISO 9000 1987) De IS0-9000-serie voor kwaliteit wordt sinds enkele jaren in de software-industrie gehanteerd door bedrijven die streven naar certificatie van de kwaliteit van hun voortbrengingsproces. ISO 9000 betreft een algemene normenserie die geldt voor alle takken van industrie. Eerst sinds enkele jaren (1991) is de ISO 9000-3 norm verschenen die speciaal voor de software-industrie is ontwikkeld. In deze voor de software-industrie specifieke standaard wordt voortgebouwd op eerder verschenen standaards voor software-ontwikkeling van de IEEE (IEEE 1984). Omdat bedrijven vooralsnog niet gecertificeerd kunnen worden op deze laatste norm en omdat deze in feite een vertaling is van de algemene norm, bespreken we hier eerst de ISO 9000-normen. In hoofdstuk 4 gaan we nader in op de ISO 9000-3 normen. Centraal staat in de ISO-normen een stelsel van kwaliteitsbegrippen. We beschrijven kort de belangrijkste begrippen en hun onderlinge relaties. Kwaliteitszorg

dat aspect van de totale management-functie dat het kwaliteitsbeleid bepaalt en ten uitvoer brengt.

Kwaliteitsbeleid

de doelstellingen van een organisatie ten aanzien van kwaliteit, alsmede de wegen en de middelen daartoe, zoals deze formeel tot uitdrukking komen in een verklaring van de directie. 17

Kwaliteit in het informatiesystemen- en softwaregebied Kwaliteitszorg en kwaliteitsbeleid behoren tot de meest abstracte begrippen binnen de ISOstandaards. Uitgaande van deze begrippen is gepoogd voorschriften en richtlijnen op te stellen voor de ontwikkeling van kwaliteitssystemen. Een kwaliteitssysteem wordt als volgt omschreven: Kwaliteitssysteem

de organisatorische structuur, verantwoordelijkheden, procedures, processen en voorzieningen voor het ten uitvoer brengen van kwaliteitszorg.

Binnen een kwaliteitssysteem ligt het accent op het plannen, beheersen en controleren van de kwaliteit. Het doel van een kwaliteitssysteem kan met behulp van een lshikawa-diagram (een oorzaak/gevolg-schema (lshikawa 1985)) als volgt worden voorgesteld (Rienstra 1991).

kwaliteitsbeheersing

mensen

kwaliteitscontrole

met~oden

>------+----++---+ materfaal

ma~nes

produlct

systeem voor kwaliteitsborging

Figuur 2.3 Kwaliteit: controle, beheersing en horging (Rienstra 1991) \

De begrippen in de figuur worden door ISO 9000 als volgt omschreven:

Kwaliteitsbeheersing de operationele technieken en activiteiten die worden (oegepast om aan kwaliteitseisen te voldoen. Kwaliteitsbeheersing heeft bijvoorbeeld betrekking op bijsturing van het proces of het tijdens het proces herstellen van waargenomen fouten of afwijkingen. Kwaliteitscontrole

de activiteiten zoals meten, onderzoeken, beproeven, keuren met kalibers van een of meer kenmerken van een produkt of dienst en het vergelijken van uitkomsten met gestelde eisen, om te bepalen of aan deze is voldaan. Controles vinden in deze omschrijving altijd plaats na afloop van het voortbrengingsproces.

Kwaliteitsborging

het geheel van alle geplande en systematische acties nodig om in voldoende mate het vertrouwen te geven dat een produkt of dienst voldoet aan de gestelde kwaliteitseisen. Van kwaliteitsborging kan worden gesproken wanneer erop wordt toegezien of kwaliteitscontrole en -beheersing systematisch worden gepland en uitgevoerd.

18

Hoofdstuk 2

In de ISO-opvatting over kwaliteit ligt een belangrijk accent op procedures en richtlijnen voor het plannen en controleren van de kwaliteit Daarmee bestaat er een verwantschap tussen deze benadering van kwaliteit en de 'manufacturing based' definities volgens Garvin. kwaliteit volgens Total Quality Management (Oakland 1989) Van recente datum is de belangstelling in de software-industrie voor de Total Quality Management-benadering (Jarke en Pohl 1992, Gillies 1992). Belangrijk kenmerk van deze benadering is dat wordt gestreefd naar een integrale aanpak voor de continue verbetering van de bedrijfsvoering, zie onder andere (Oakland 1989, Boddendijk 1992). Daar behoren ook de relaties met de afnemer toe. De mens, zowel individueel als in groepsverband, wordt gezien als een van de sleutelfactoren. De betrokkenheid van het management is een belangrijke voorwaarde om verbeteringsvoorstellen te bekrachtigen en te implementeren. In (Philips Corporate Quality Bureau 1993) worden in het kader van TQM twee belangrijke taken van het management beschreven, die respectievelijk worden genoemd 'policy deployment' en 'process management'. Onder 'policy deployment' wordt verstaan de vertaling van bedrijfsdoelstellingen naar kwaliteitszorgactiviteiten op de verschillende besturingsniveaus in de organisatie. 'Process management' is gericht op de vertaling van klantwensen door een (horizontale) keten van bedrijfsfuncties ('van zand tot klant'). Gelet op het integrale karakter van TQM zijn binnen deze kwaliteitsbenadering meerdere definities van Garvin van toepassing. Samenvatting Kwaliteit van systemen en software kan vanuit verschillende invalshoeken worden benaderd. Dat blijkt wanneer we deze benaderingen positioneren tegen de achtergrond van het werk van Garvin. Afwisselend ligt het accent op het inbouwen van kwaliteit als produktkenmerken in softwareprodukten of op het plannen, controleren en verbeteren van kwaliteit tijdens het voortbrengingsproces. De beschreven benaderingen volgens Boehm en Cavano en McCall en volgens ISO 9000 kunnen worden beschouwd als representanten van respectievelijk de product based definities en de manufacturing based definities van Garvin. Voor wat betreft TQM is het niet mogelijk om eenduidig relaties te leggen met een of meerdere definities van Garvin. De reden daarvan is dat binnen TQM wordt gestreefd naar een integrale aanpak van zowel proces-, produkt- als middelenaspecten (met name menskundige aspecten). In het vervolg van dit hoofdstuk wordt verslag gedaan van een onderzoek in de praktijk over behoeften en wensen op het gebied van systeemontwikkeling. Opgemerkt wordt dat dit empirische onderzoek niet expliciet betrekking had op het begrip kwaliteit Doel was een zo volledig mogelijk overzicht te krijgen van de belangrijkste vraagstukken en knelpuntgebieden in de praktijk van informatiesysteemontwikkeling. Zoals eerder gesteld in dit hoofdstuk vormen de resultaten van het praktijkonderzoek mede de uitgangspunten en randvoorwaarden voor respectievelijk het ordenen van kwaliteitsopvattingen en het omgaan met kwaliteit

19

Kwaliteit in het informatiesystemen- en softwaregebied

2.4

Praktijkproblemen: een empirisch onderzoek

In deze paragraaf bespreken we de resultaten van een empirisch onderzoek naar de opvattingen en meningen van ervaren specialisten ten aanzien van problemen en prioriteiten met betrekking tot noodzakelijke verbeteringen in het ontwikkelwerk. Het empirisch onderzoek werd uitgevoerd bij 16 Nederlandse bedrijven. Zoals zal blijken worden door de praktijkmensen enkele opvallende accenten gelegd en prioriteiten gesteld met betrekking tot verbetering van het ontwikkelwerk. De praktijk wenst niet zomaar iets nieuws te accepteren. Men verwacht en eist van nieuwe methodische aanvullingen dat wordt aangegeven op welke punten in het ontwikkelwerk verbeteringen te verwachten zijn. Tevens moet worden waargemaakt welke de positieve effecten zijn van die verbeteringen. Door een bespreking van vijf 'kernopinies' uit de praktijk worden de belangrijkste resultaten van de interviews uiteengezet. In paragraaf 2.4.1 beschrijven we eerst in het kort de doelstelling en de opzet van het onderzoek aan de hand van de gespreksthema's die tijdens de interviews centraal stonden. Een toelichting en verantwoording van de gevolgde werkwijze in dit empirische onderzoek wordt beschreven in paragraaf 2.4.2. Vervolgens worden in paragraaf 2.4.3 per gespreksthema de betreffende 'kernopinies' beschreven alsmede een toelichting op de onderwerpen die per gespreksthema aan de orde werden gesteld.

2.4.1 Het onderzoek Het doel van het onderzoek was om opvattingen en meningen in de praktijlt. te 'peilen' over gewenste en noodzakelijke verbeteringen in het ontwikkelwerk. Heti onderzoek had voornamelijk een exploratief en beschrijvend karakter. Vooraf zijn . gespreksthema's geformuleerd die in diepte-interviews aan de orde zijn gesteld. De gespreksthema's zijn bepaald op grond van literatuuronderzoek en ervaringen van de onde~kers die bij het project waren betrokken. We geven een beknopte beschrijving van de gespreksthema's. Thema 1: Het 'contingentie' thema Velen menen dat één en slechts één alomvattende methode zou bestaan waarmee alle informatieproblemen kunnen worden opgelost: Wij delen die opvatting niet. Daarom werd binnen dit thema de contingentiestelling getoetst 'verschillende methoden en gereedschappen voor verschillende situaties'. Thema 2: Het thema van de verschillende ontwikkelaspecten Dit thema heeft betrekking op de verschillende aspecten modelleren, beheersen, balanceren, leren en veranderen die in de literatuur worden onderscheiden bij het ontwikkelen van informatiesystemen. In de interviews werd getoetst welke ontwikkelaspecten in de praktijk worden onderkend, in hoeverre deze op operationele 20

Hoofdstuk 2 wijze worden ondersteund en welke van de aspecten de hoogste prioriteit krijgen voor verbetering. Thema 3: Het thema van de veranderingsbereidheid Uitgangspunt in dit thema is dat de ontwikkelpraktijk de laatste jaren is overspoeld met nieuwe methoden, technieken en geautomatiseerde gereedschappen, onder andere CASE-tools. Methoden en gereedschappen zijn niet meer weg te denken bij systeemontwikkeling. Naast kwaliteitsverbeteringen worden ook genoemd verhoging van de productiviteit van de ontwikkeling; versnelling van de oplevering van het te ontwikkelen systeem; kostenreductie van de ontwikkeling etcetera. Daar tegenover staan uiteraard extra kosten en inspanningen om nieuwe methoden en gereedschappen in te voeren en te leren gebruiken. In dit thema werd aan de orde gesteld in hoeverre methoden en gereedschappen verankerd zijn in het ontwikkelwerk, waar tekorten liggen en in welke mate en onder welke voorwaarden veranderingen c.q. verbeteringen worden geaccepteerd. Binnen elk van de thema's werden door middel van open vragen over verschillende onderwerpen de meningen en opvattingen van gernterviewden gepeild.

2.4.2 Verantwoording van het type onderzoek en de gevolgde werkwijze Het type onderzoek Dit onderzoek werd in 1990 in het kader van contractresearch voor het Software Engineering Centre (Serc) uitgevoerd, zie onder andere (Trienekens en Van Reeken 1992). Het moge duidelijk zijn dat het onderzoek zich niet richtte op een bepaald aspect van het ontwikkelwerk, bijvoorbeeld het analyseren van informatiebehoeften of het beheersen van de doorlooptijd. De reden is dat in literatuur en praktijk geen duidelijkheid of eensgezindheid bestaat over de factoren die bij systeemontwikkeling de grootste problemen veroorzaken en om de meeste aandacht vragen. Olie et al (1988) en Lindgreen et al (1990) stellen het inhoudelijk modelleren centraal, ofwel het analyseren en ontwerpen van de structuur van informatiesystemen. Voor Boehm et al (1988) en Basili (1993) vormen de beheersaspecten, c.q. tijd, geld en kwaliteit, de kern van informatiesysteem- en softwareresearch. Beide onderzoeksscholen belichten vragen en knelpunten vanuit een verschillende invalshoek. Ook de resultaten van kwantitatief empirisch onderzoek in Nederland naar het toepassen van theorie en methoden en gereedschappen geven slechts ten dele inzicht in de vraagstukken en knelpunten waarmee praktijkmensen momenteel te kampen hebben, zie onder andere (Wijers en van Dort 1990, Kusters en Wijers 1992). Om meer inzicht te krijgen in de essentiële problemen en knelpunten en de prioriteiten voor verbetering ontstond de behoefte om zelf te kijken in de praktijk. Daarbij werd gekozen voor een kwalitatieve, c.q. een exploratieve en beschrijvende, aanpak. Dit betekent dat de aard van de vragen die de onderzoekers wensten te stellen en het te verwachten type antwoorden (c.q.

21

Kwaliteit in het itifonnatiesystemen- en softwaregebied

opinies, ervaringen, afwegingen etcetera) zich niet lenen voor uitvoerige statistische analyses. Kenmerkend voor kwalitatief onderzoek is dat begonnen wordt met een globale omschrijving van een onderzoeksgebied (hier aan de hand van een beschrijving van thema's), dat het zich richt op het verzamelen van meningen (hier door middel van diepte-interviews) en dat vervolgens theorievorming ontstaat (Strauss en Corbin 1991).

De werkwijze De praktijk werd letterlijk aan het 'woord' gelaten. Na een zorgvuldig selectieproces werden zestien grote organisaties geselecteerd. Onder deze organisaties bevonden zich belangrijke softwarehuizen, grote industriè1e organisaties, overheidsinstanties en organisaties uit de zakelijke dienstverlening (banken, verzekeringsmaatschappijen). Per organisatie werden telkens twee functionarissen geïnterviewd, te weten een projectmanager en een inhoudelijk ontwikkelspecialist. Beide functionarissen waren senioren in leidinggevende functies met een veeljarige ervaring. Het betrof hier mensen met overzicht, waarvan men een visie kon verwachten. De thema's die voor het onderzoek zijn beschreven zijn eerst in een tweetal 'pilot'-interviews getoetst Vervolgens heeft een aanscherping van de gespreksthema's plaatsgevonden. Voor de interviews werd gebruik gemaakt van gestructureerde diepte-interviewtechnieken. Elk interview duurde ruim twee uur waarbij door een interviewteam (bestaande uit een interviewer en een of twee protocollisten), een interviewprotocol werd doorlopen. De interviewers waren universitair docenten met praktijkervaring op het gebied van het methodisch ontwikkelen van informatiesystemen. Alle gestelde vragen en antwoorden werden uitgewerkt en retour gezonden aan de geïnterviewden met het verzoek deze overzichten te controleren en zonodig aan te vullen of te wijzigen. De terug ontvangen resultaten zijn vervolgens geordend door het interviewteam. De onderzoeksresultaten zijn vervolgens vanuit verschillende gezichtspunten verder uitgewerkt, zie onder andere (Trienekens en Van Reeken 1992).

2.4.3 De praktijk aan het woord: interviewthema's, kernopinies en gespreksonderwerpen Dat kwalitatief onderzoek vaak meer vragen oproept dan beantwoordt is algemeen bekend. Toch hebben wij uit de veelheid aan meningen en ervaringen die ons werden toegespeeld, vijf 'kern' -opinies uit de praktijk kunnen afleiden. De vijf kernopinies zijn ontstaan na groepering van de antwoorden en de reacties van geïnterviewden op de open vragen rond de drie interviewthema' s. Om de betekenis van de kernopinies tot hun recht te laten komen wordt elk interviewthema kort toegelicht met een beschrijving van de gespreksonderwerpen die met betrekking tot dat thema aan de orde werden gesteld en de meningen van respondenten. Interviewtbema 1: bet 'contingentie'·tbema De reacties en meningen van geïnterviewden ten aanzien van dit thema laten zich samenvatten in twee kernopinies. We geven een toelichting op de kernopinies en beschrijven vervolgens kort de gespreksonderwerpen die binnen dit thema aan de orde kwamen. 22

Hoofdstuk 2

Kernopinie Het afdekken van de gehele levensloop van infonnatiesystemen en software (ook wel 'life cycle' genoemd) met één universele methode en gereedschap wordt door maar weinig bedrijven nodig geacht De gernterviewde projectmanagers hebben zelden de verantwoordelijkheid voor een infonnatiesysteem vanaf de infonnatieplanningsfase tot en met de uiteindelijke vervanging van het systeem door een nieuw produkt met alle daartussen liggende fasen van ontwikkeling, beheer en onderhoud. In het overgrote deel van de gevallen is men slechts voor enkele fasen verantwoordelijk. Ook het bedrijf waartoe de projectmanager behoort, is in het merendeel van de gevallen maar voor enkele fasen competent of verantwoordelijk. Er zijn organisaties en afdelingen die zich gespecialiseerd hebben in infonnatieplanning en die voor het vervolg ofwel de verantwoordelijkheid overdragen aan een andere afdeling, ofwel dat uitbesteden aan andere organisaties. Sommige organisaties of afdelingen hielden zich naast analyse en ontwerp ook nog bezig met het onderhoud terwijl de constructie werd uitbesteed. Weer andere organisaties of afdelingen houden zich met alles bezig behalve met het onderhoud van de ontwikkelde infonnatiesystemen. Ook troffen wij een bedrijf aan dat zelf de infonnatieplanning en het onderhoud van de ontwikkelde systemen deed, maar de ontwikkeling had uitbesteed aan een firma die de constructie weer aan een derde bedrijf had uitbesteed. Binnen vrijwel geen van de bedrijven van gernterviewden bestaat veel interesse om gezamelijk met andere bedrijven te streven naar een 'universele' methode met bijbehorende gereedschappen. Men is van mening dat de zegeningen daarvan niet opwegen tegen de benodigde investeringen. Onder andere wordt dit veroorzaakt door de beperkingen van de huidige state-of-the-art van de theorie, de methoden, de gereedschappen en de standaards daaromtrent Iedereen heeft zijn eigen voorkeuren, op basis van opgedane ervaringen en accepteert vooralsnog dat die ervaringen elders anders kunnen zijn. Kernopinie lnfonnatiesysteem- en software-ontwikkelaars hebben behoefte aan flexibiliteit, met name ten aanzien van de beheersing van het ontwikkelwerlc. De wijze van projectbeheersing is bij elk bedrijf gebaseerd op de lineaire ontwikkelstrategie, een aantal keren werd ook het watervalmodel genoemd. Veel van onze respondenten zeiden behoefte te hebben aan alternatieven voor deze lineaire aanpak. Alternatieve beheersaanpakken werden aangeduid met prototyping, incrementeel en evolutionair. Ervaringen had men daar overigens nauwelijks mee opgedaan. Met betrekking tot gewenste veranderingen c.q. verbeteringen werd vaak de opmerlcing gemaakt dat de betrokken organisaties alternatieve beheersaanpakken alleen zouden accepteren wanneet kon worden aangegeven hoe deze in de praktijk moeten worden toegepast, en onder welke omstandigheden welke voordelen daarmee kunnen worden behaald, in het bijzonder ten aanzien van de beheersing van tijd, geld en kwaliteit.

23

Kwaliteit in het informatiesystemen- en softwaregebied We lichten de kernopinies verder toe met een beschrijving van de gespreksonderwerpen binnen dit interviewthema en de meningen van respondenten tijdens de interviews. De drie belangrijkste gespreksonderwerpen met betrekking tot 'contingentie' waren respectievelijk:

he~

interviewthema

fasen of clusters werk van systeemontwikkeling strategieën van systeemontwikkeling toepassingsgebieden We bespreken deze gespreksonderwerpen achtereenvolgens. Gespreksonderwerp I: fasen of clusters werk in systeemontwikkeling Voor het onderzoek werd in eerste instantie een fasering gebruikt die is afgeleid van (Boehm 1988). Daarin worden de volgende hoofdfasen onderscheiden: informatieplanning definitiestudie · analyse ontwerp coderen en testen invoeren onderhoud Al snel bleek uit de meningen van respondenten dat het woordgebruik verschilt van organisatie tot organisatie. Wat bijvoorbeeld de één ontwerp noemt. wordt door de and~r nog als analyse gezien. Van uniformering en standaardisatie is vrijwel geen sprake. Verder bleek dat de praktijk minder fasen onderscheidt dan de verlijnde indelingen in de literatuur. Op grond van het voorgaande is een herziene indeling gekozen die in de meeste interviews aansprak. Deze indeling is: informatieplanning analyse en ontwerp van een applicatie constructie, inclusief testen invoering onderhoud

Tijdens de interviews werd door veel van de geü:iterviewden opgemerkt dat een indeling in fasen in de praktijk niet echt 'werkt'. Men kan beter spreken van "clusters van soorten werk" dan van fasen. Het ontwerpproces, onder andere de volgorde waarin de verschillende activiteiten worden uitgevoerd, verloopt anders dan de achteraf op een rij .gezette resultaten (lees: specificaties) van dat proces doen vermoeden. Ook in de literatuur is;dit verschijnsel al verschillende malen beschreven, zie onder andere (van Vliet 1993).

24

Hoofdstuk 2 Duidelijk werd dat met betrekking tot bovengenoemde clusters van werkzaamheden binnen organisaties de volgende typen methoden en gereedschappen worden onderscheiden: methoden methoden methoden methoden

en gereedschappen en gereedschappen en gereedschappen en gereedschappen

voor informatieplanning voor analyse/ontwerp voor het bouwen (en testen) voor projectmanagement

Speciale methoden en gereedschappen voor invoering (bijvoorbeeld: opleiding) werden niet genoemd. Ook werden geen signalen ontvangen over de beschikbaarheid over methoden en gereedschappen voor het operationele beheer van informatiesystemen. Gespreksonderwerp 2: strategiei!n van systeemontwikkeling In de interviews werd onderscheid werd gemaakt tussen verschillende ontwikkelstrategiei!n (lineair, prototyping, evolutionair etcetera (van Vliet 1993)). We lichten deze beknopt toe.

Volgens de lineaire ontwikkelstrategie dienen de verschillende fasen achtereenvolgens te worden doorlopen. Dit houdt in dat men eerst aan een volgende fase kan beginnen (bijvoorbeeld na de analyse- de ontwerpfase) wanneer alle deelprodokten uit een voorgaande fase volledig zijn afgerond en opgeleverd. Een verbijzondering van deze strategie wordt geboden door het welbekende watervalmodel (Boehm 1976). In dit model wordt benadrukt dat de in elke fase verkregen resultaten uitvoerig dienen te worden geverifieerd en te worden gevalideerd voordat aan een volgende fase mag worden begonnen. In principe mag het werken binnen een fase niet tot gevolg hebben dat activiteiten die tot voorgaande fasen behoren opnieuw worden uitgevoerd. In geval van prototyping worden de verschillende fasen achtereenvolgens meerdere keren

doorlopen. Telkens ontstaat een prototype van een informatiesysteem. Ben prototype is een werkend model van een informatiesysteem waarin bepaalde aspecten van dat systeem worden benadrukt (Vonk 1987). Prototypes worden gemaakt om afnemers snel potentil!le voordelen van automatisering te laten zien. Ook wordt het mogelijk voor afnemers om precieze en aanvullende specificaties van een informatiesysteem te beschrijven (bijvoorbeeld met betrekking tot de mensmachine-interface). Belangrijk verschilpunt met de lineaire strategie of met het watervalmodel is dat tijdens het tot stand komen van een informatiesysteem een afnemer meerdere keren (elk prototype) wordt geconfronteerd met de werking van (componenten van) een gewenst infomatiesysteem. In ontwikkelsituaties waar grote onzekerheid bestaat, bijvoorbeeld met betrekking tot de acceptatie van gebruikers of met betrekking tot de veranderingen die een organisatie doormaakt, is doorgaans een andere strategie vereist. Evolutionair ofincrementeel ontwikkelen houdt in dat de gevraagde functionaliteit en kwaliteitsaspecten van een informatiesysteem in stappen wordt ontworpen en gerealiseerd (Gilb 1988). In elke stap kan de gefaseerde aanpak volgens het watervalmodel worden toegepast of kan prototyping plaatsvinden. De organisatie krijgt na elke stap de tijd om het systeem te laten integreren in de bedrijfsvoering waarna

25

Kwaliteit in het informatiesystemen- en softwaregebied aanvullende eisen en wensen worden gespecificeerd. Doel is dat een informatiesysteem zich ontwikkelt in wisselwerking met een organisatie. Meningen van respondenten De praktijk van informatiesysteemontwikkeling wordt gekenmerkt door een grote diversiteit aan ontwikkelactiviteiten en ontwikkelmethoden. De beperkingen van één 'standaard' lineaire projectaanpak worden in de praktijk alom onderkend. Naast flexibel toepasbare alternatieve ontwikkelstrategielSn zeiden respondenten behoefte te hebben aan een goed contingentieraamwerk, waarin duidelijk is aangegeven bij welke situaties welke soort beheersing gewenst en noodzakelijk is. Zonder een duidelijk zicht op de toepasbaarheid •van alternatieve ontwikkelaanpakken op basis van de karakteristieken van probleemsituaties zei men het zich niet te kunnen veroorloven af te stappen van de 'lineaire' ontwikkelaanpak; Gespreksonderwerp 3: toepassingsgebieden. Tijdens de interviews werd ook onderscheid gemaakt tussen toepassingsgebieden van informatiesystemen. Gebruik werd gemaakt van een typologie van infonnatiesystemen die werd afgeleid uit de literatuur (Zijlker 1987). In deze typologie wordt onderscheid gemaakt tussen respectievelijk: gegevensintensieve toepassingen: systemen met massale databestanden maar relatief eenvoudige bewerkingen procesintensieve toepassingen: systemen met rekenintensieve bewerkingen zoals optimalisatiemodellen, procesbesturing etc. communicatie-intensieve systemen: systemen gericht op data- en berichtuitwisseling Meningen van respondenten Hoewel men ook op dit gebied verschilde qua tenninologie en qua indelingscriteria konden de respondenten zich vinden in deze typering. Echter: trends of harde . conclusies met betrekking tot specii.teke aanpakken, werkwijzen, methoden en gereedschappen werden door de respondenten niet gegeven; met name omdat het niet mogelijk bleek meer dan globale of intullieve karakteristieken te geven voor ieder van de toepassingsgebieden. Uit de kernopinies met betrekking tot het 'contingentie-thema' lijkt de praktijk de opvatting "verschillende werkwijzen, methoden en gereedschappen voor verschillende situaties" te onderschrijven. Deze opvatting is gebaseerd op enerzijds de grote diversiteit aan probleemen ontwikkelsituaties en anderzijds op de veelheid aan beschikbare methoden en gereedschappen. Men is van mening dat de ontwikkeling van een universele aanpak en methode te hoge investeringen zal vergen. Ook vreest men dat een 'standaardmethode' eerder een verstarring tot gevolg zal hebben van het ontwikkelwerk dan dat daarmee verbeteringen kunnen worden bewerkstelligd. Verder moet de kanttekening worden gemaakt dat methodische vernieuwingen alleen worden geaccepteerd als wordt aangegeven op welke manier ze in de praktijk moeten worden toegepast en welke verbeteringen kunnen worden verwacht 26

Hoofdstuk 2

Interviewthema 2: Ontwikkelaspecten De meningen die \\:'erden geYnventariseerd met betrekking tot dit thema laten zich samenvatten in een derde kernopinie.

Kernopinie Praktijkmensen geven momenteel de hoogste prioriteit aan het verbeteren van de beheersbaarheid van ontwikkelprojecten

In de praktijk van de systeemontwikkeling is beheersing van systeemontwikkeling het allerbelangrijkste ontwikkelaspect, niet alleen voor projectmanagers maar ook voor methodenspecialisten. Uiteraard hangt dit samen met het . feit dat men voornamelijk 'afgerekend' wordt op het binnen tijd en budget realiseren van een project Het belang van methoden en gereedschappen wordt afhankelijk gesteld van de mate waarin ze bijdragen aan de beheersing van het ontwikkelwerk. Vooralsnog blijkt beheersen synoniem te zijn voor faseren, organiseren en documenteren. Daarmee vergeleken was, ten tijde van het onderhavige praktijkonderzoek, kwaliteitsbeheersing een onderbelicht gebied. Het belangrijkste gespreksonderwerp met betrekking tot het interviewthema 'ontwikkelaspecten' had betrekking op de verschillende ontwikkelaspecten die kunnen worden onderscheiden in het ontwikkelwerk, zie Bemelmans (1990). Aspecten zijn:

Modelleren

Men kan geen infonnatiesysteem maken zonder een goede beschrijving of model. Om modellen te maken zijn methoden en gereedschappen nodig voor onder andere het maken van activiteitsdiagrammen, data-diagrammen, etc.

Balanceren

Balanceren heeft betrekking op het maken van afwegingen bij het nemen van ontwerpbeslissingen tijdens het ontwikkelwerk. We geven een voorbeeld. Naast aangeven Wat een systeem kan en moet (functionele eisen), zal men ook moeten aangeven aan welke kwaliteitseisen dat systeem moet voldoen. Kwaliteitseisen zijn onder andere eisen met betrekking tot snelheid, omvang, flexibiliteit, gebruikvriendelijkheid, onderhoudbaarheid, beveiliging etcetera. Bij het vaststellen van dergelijke eisen geldt dat elke invulling van een eis een eigen "prijskaartje" kent Men zal dus moeten afwegen (balanceren) wat men over heeft voor een bepaalde mate van beveiliging of voor een bepaalde mate van flexibiliteit etcetera.

Beheersen

Elk: (ontwikkelings)project vergt beheersing naar tijd, geld, kwaliteit, organisatie, communicatie. In dit stramien vallen zaken zoals projectorganisatie, fasering, kwaliteitsbewaking, documentatie, etcetera. Methoden in dat verband zijn onder andere SDM (CapNolmac), Promis (BSO), Projectmatig Werken (Twijnstra Gudde) en dergelijke.

27

Kwaliteit in het informatiesystemen- en softwaregebied Veranderen Het invoeren van infonnatiesystemen vergt steeds een veranderingsproces binnen een organisatie. Ook dat vergt een methodische aanpak waarbij diverse bedrijfskundige methoden en gereedschappen vereist zijn.

Leren

Elk ontwikkelingsproces levert nieuwe kennis en ervaring op, alsmede (mits daarop georganiseerd) herbruikbare systeempatronen en software. Opnieuw vergt dit aspect aparte methoden en gereedschappen.

Meningen van respondenten In de interviews ging de aandacht van geïnterviewden vooral uit naar de o,ntwikkelaspecten modelleren en beheersen, iets dat correspondeert met de "state of the art" in de literatuur. De andere aspecten: balanceren, leren en veranderen worden weinig onderkend en worden in de praktijk slechts zelden methodisch ondersteund. Zoals gezegd werd aan het ontwikkelaspect beheersen de hoogste prioriteit gegeven waarbij vooralsnog eenzijdig de nadrUk ligt op faseren en documenteren. Wat betreft het belang van methoden en gereedschappen voor de beheersbaarheid werd vastgesteld dat men te weinig "meet" en dus te wein\g "weet". Het is een teken van de tijd dat vrijwel alle organisaties het aspect beheersen als topprioriteit één beschouwen. Projectplanning is nog altijd een zorgenkind. Projecten zijn! te laat af, kosten meer dan geraamd, de opgeleverde produkten voldoen niet aan gebruikerseisen etcetera. Beheersen is vooralsnog beperkt tot het bewerkstelligen van unifonniteit van taal en controleerbaarheid van handelen, ofwel faseren (de beheersaspecten tijd en geld) en documenteren (het beheersaspect infonnatie). Het beheersaspect kwaliteit is vooralsnog nauwelijks operationeel en werd ook nauwelijks met concrete methoden en, gereedschappen ondersteund.

Interviewthema 3: Veranderingsbereidheid De meningen die met betrekking tot dit thema werden geïnventariseerd laten zich samenvatten in twee kernopinies die we beschrijven en toelichten.

Kernopinie Het invoeren van nieuwe (en betere) methoden en gereedschappen voor het ontwikkelwerk heeft ook nadelen. Het invoeren van methoden en gereedschappen is een proces van moeizame interne afstemming en kost veel moeite en tijd. Projectmanagers blijken liever een project in te gaan met niet-'State of the Art' methoden en gereedschappen waarmee men echter ervaring heeft, dan de beheersbaarheid van het project te riskeren door het volgen van alternatieve werkwijzen of het toelaten van nog niet goed ingevoerde methoden en gereedschappen. We merken op dat dit in schril contrast staat met de vele inspanningen die software-ontwikkelaars zich getroosten om hun klanten over te halen hun bedrijfsvoeringen aan te passen en te automatiseren. Ter compensatie van de nadelige effecten van de invoering van nieuw~ methoden en

28

Hoofdstuk 2 gereedschappen wensen met name projectmanagers voorwaarden te stellen met betrekking tot de aantoonbaarheid van de voordelige effecten. Voordelige effecten zouden minstens zo groot moeten zijn als de (vele) moeite en kosten in verband met afstemming die invoering van de methode of het gereedschap met zich meebrengt. Wat dat betreft betekent invoeren van methoden en gereedschappen expliciet afwegingen maken tussen voor· en nadelen. Kernopinie Bestaande methoden en gereedschappen vertonen bij gebruik te veel hinderlijke eigenschappen, waardoor het twijfelachtig is of de beloofde en verwachte voordelen kunnen worden behaald. Hinderlijke eigenschappen die worden genoemd zijn: methoden en gereedschappen bevatten te weinig ondersteuning voor het meten en evalueren van resultaten het aanbrengen van kleine wijzigingen in methoden en gereedschappen vereist veel inspanning en hoge kosten de in gebruik zijnde methoden schieten tekort op het vlak van het onderhoud van informatiesystemen Het belangrijkste gespreksonderwerp met betrekking tot het interviewthema 'veranderingsbereidheid' was het belang van het onderkennen van groeistadia van methoden en gereedschappen. We geven een beknopte toelichting. Elke technologie, elke methode en elk gereedschap wordt niet zo maar in een organisatie opgenomen, maar doorloopt een bepaald groeipad. Daarbij kan men de volgende groeistadia onderkennen (Bemelmans 1991 ): Initiatie:

Kleinschalig experimenteert men met de technologie om te bepalen of het nut heeft voor de organisatie.

Diffusie:

Na bewezen potentie, verspreidt de technologie zich "organisatiebreed".

Consolidatie: Men is vertrouwd met de nieuwe technologie en haalt er uit wat er in zit (uitbating). Integratie:

Men integreert de technologie in de infrastructuur aan middelen (soms verdwijnt de technologie later door substitutie door een betere).

Uiteraard verloopt de overgang tussen de fasen niet vanzelf. Vaak zijn ingrijpende organisatieveranderingsprocessen noodzakelijk die gepaard gaan met hoge kosten en inspanningen.

29

Kwaliteit in het informatiesystemen- en softwaregebied Meningen van respondenten De meeste ondervraagden herkenden bovengenoemde groeistadia voor methoden en gereedschappen. Vele methoden zouden in de diffusie- en zelfs consolidátiefase verkeren. Gereedschappen daarentegen bevinden zich meestal in de initiátiefase en maar meidendenteel in de diffusiefase. Samenvattend kan worden gesteld dat slechts weinigen van de geïnterviewden hun zinnen zetten op het aanschaffen van geheel nieuwe methoden en gereedschappen. Methoden en gereedschappen hebben veel geld en inspanning gekost en zijn nog niel volledig benut Hoofddoel lijkt momenteel het meer efficient en effectief leren werken· met de huidige methoden en gereedschappen. Veranderingen worden alleen geaccepteerd wanneer deze aansluiten op gevestigde werkwijzen en wanneer concreet wordt aangetoond wat de voordelen zijn.

2.5

Samenvatting en conclusies

De beschrijving van enkele bekende benaderingen van kwaliteit in de literatuur, tegen de achtergond van de kwaliteitdefinities van Garvin, maakt de verschillende perspectieven duidelijk van waaruit kwaliteit wordt benaderd in de informatiesystemen- en softwarewereld. De benaderingen 'van het eerste uur', zoals ze in dit hoofdstuk zijn genoemd, van Boehm en Cavano en McCall zijn met name op technische produktaspecten georiënteer4. Aandacht voor de afnemer is uiterst beperkt. De ISO 9000 standaards zijn vrijwel uitsluitend gericht op het plannen en controleren van de kwaliteit tijdens het ontwikkelwerk (lees: het ;proces). Gesteld kan worden dat deze benaderingen verwant zijn met respectievelijk de product based en de manufacturing based definities van Garvin. Binnen Total Quality Management dat het omgaan met kwaliteit integraal poogt te benaderen, zijn meerdere definities van Garviri van toepassing. In dit hoofdstuk is vervolgens een exploratief onderzoek beschreven naar knelpunten van het gebruik van methoden en gereedschappen in de praktijk. Op de vraag aan de praktijk of de huidige werkwijzen, methoden en gereedschappen adequaat en effectief bijdragen aan kwaliteit geven de resultaten van het praktijkonderzoek noch een bevestigend, noch een ontkennend antwoord. Nog altijd geldt: men meet niet en dus weet men niet. De behoeften van praktijkmensen lijken in eerste instantie gericht te zijn op een verbetering van de flexibiliteit (onder meer voor wat betreft de toepassing van methoden en gereedschappen) en de beheersing (onder meer voor wat betreft het toepassen van altemátieve ontwikkelstrategieën). Tevens is duidelijk geworden dat de praktijk open staat voor vernieuwing en verbetering, maar niet 'zomaar'. Verbeteringsvoorstellen dienen rekening te houden met bestaa:nde denkwijzen en werkwijzen binnen de organisatie en dienen aantoonbaar nut te hebben. Terugblikkend op het voorgaande kan worden gesteld dat zowel de literatuur als de praktijk slechts een fragmentarisch beeld heeft van de verschillende aspecten van het 'Ontwikkelwerk. Daarom wordt in het volgende hoofdstuk allereerst een samenhangend beeld van systeemontwikkeling gegeven. Aangegeven wordt op welke (deel)aspecten de in dit hoofdstuk

30

Hoofdstuk 2 aan de orde gestelde benaderingen van kwaliteit betrekking hebben. Hoofdstuk 3 zal vervolgens als referentiekader worden gebruikt voor respectievelijk het ordenen van kwaliteitsopvattingen (hoofdstuk 4) en het verbeteren van de hanteerbaarheid van het begrip kwaliteit (hoofdstukken 5. 6 en 7). Dit laatste wordt met name toegespitst op de ontwikkeling van een methode voor het identificeren en specificeren van kwaliteitseisen.

31

3

NAAR EEN SAMENHANGEND BEELD VAN HET ONTWIKKE· LEN VAN INFORMATIESYSTEMEN

3.1 Inleiding De infonnatiesystemenwereld ontwikkelt zich van een relatief jong naar een volgroeid vakgebied. Het empirisch onderzoek dat werd beschreven in het voorgaande hoofdstuk bevat verschillende aanwijzingen daarvoor. In hoofdstuk I is reeds aangegeven dat nadat het accent heeft gelegen op het realiseren van functionaliteit en het tijdig en tegen aanvaardbare kosten opleveren van infonnatiesystemen het accent momenteel verschuift naar het leveren van een meerwaarde die kwaliteit wordt genoemd. Makers blijken in de praktijk verbetering na te streven door een verdere uitnutting van methoden, technieken en gereedschappen en een selectieve en stapsgewijze verbetering in aanpak en werkwijze (zie hoofdstuk 2). Dit boek wil een bijdrage leveren aan het verbeteren van infonnatiesysteemontwikkeling door kwaliteit bespreekbaar en hanteerbaar te maken tussen afnemers en makers. Uitgangspunt is dat kwaliteit van infonnatiesystemen een multi-dimensionaal fenomeen is. Om daadwerkelijk over kwaliteit van infonnatiesystemen te kunnen spreken, en niet over kwaliteit op slechts een (technische) dimensie wordt in dit hoofdstuk een samenhangend beeld van essenti~le ontwikkelaspecten beschreven. Zo'n beeld ontbreekt momenteeL Ook in de literatuur is het vooralsnog niet gelukt de verschillende aspecten van systeemontwikkeling in hun onderlinge samenhang te beschouwen. Geen wonder dat praten over kwaliteit door afnemers en makers dan leidt tot misverstanden en teleurstellingen over niet ingeloste toezeggingen. Centraal staat in dit hoofdstuk het beschrijven van de verschillende ontwikkelaspecten en hun onderlinge samenhang. Uitgangspunt is een algemeen kader voor systeemontwikkeling dat we in paragraaf 3.2 introduceren. In paragraaf 3.3 wordt ingegaan op het element methodologie voor wat betreft de ontwikkelaspecten modelleren, beheersen, leren en veranderen, en balanceren. Voor elk van die ontwikkelaspecten wordt kort gerefereerd aan de in het voorgaande hoofdstuk besproken benaderingen van kwaliteit Een nadere analyse van het ontwikkelaspect balanceren leidt vervolgens tot een samenhangend model van systeemontwikkeling. Dit model dient in het vervolg van dit boek als referentiekader voor het uitwerken en operationaliseren van het begrip kwaliteit Paragraaf 3.4 sluit dit hoofdstuk af met conclusies.

3.2 Een kader voor systeemontwikkeling In figuur 3.1 wordt een algemeen kader gegeven voor systeemontwikkeling afgeleid van (Bemelmans 1990). Het kader kent de vier elementen methodologie, contingentietheorie, methoden en technieken, en (geautomatiseerde) gereedschappen. Elke ontwerper van informatiesystemen dient over kennis te beschikken van deze vier elementen en hun samenhang.

33

Naar een samenhangend beeld van het ontwikkelen van informatiesystemen

Figuur 3.1: Een kader voor systeemontwikkeling Het klakkeloos gebruiken van gereedschappen zonder kennis van methoden en technieken of het toepassen van methoden en technieken zonder enige kennis van. methodologie of contingentietheorie leidt meestal tot een inefficiënt ontwikkelproces en ineffectieve informatiesystemen. In dit hoofdstuk wordt dit algemene kader als uitgangsporit genomen om te komen tot een samenhangend beeld van het ontwikkelwerk. We lichten ,achtereenvolgens de vier elementen kort toe.

Methodologie omvat de theorie van systeemontwikkeling. Methodologie ):>eperkt zich niet alleen tot modelleringsconcepten (bijvoorbeeld van een data- of procesgeoriënteerde signatuur). Beheers-, verander-, leer-, en balanceeraspecten spelen een gelijkwaardige rol. Met betrekking tot beheersen kunnen worden genoemd het organiseren, faseren en documenteren van ontwikkelwerk. Veranderen en leren hebben onder andere betrekking op menskundige, sociale en organisatorische aspecten. Genoemd kunnen worden leeraspecten met betrekking tot houding, kennis en ervaring van ontwerpers, en organisatieveranderingsaspeeten met betrekking tot de invoering van informatiesystemen. Balancere'n is een ontwikkelaspect dat betrekking heeft op het maken van 'trade-off's' ofwel afwegingen tussen verschillende aspecten. Een bekend voorbeeld daarvan is het maken van afwegingen tussen noodzakelijke en gewenste functionaliteit van een informatiesysteem tegen inspanning, tijd en kosten.

Contingentietheorie is een element dat betrekking heeft op het afhankelijk van situationele kenmerleen kiezen voor een aanpak van het systeemontwikkelwerk of een benadering van een informatieprobleem. Dit wordt ook wel strategiebepaling genoemd. Het belang daarvan wordt duidelijk wanneer men aanpak en werkwijze vergelijkt tussen enerzijds een situatie waarin een complex informatieprobleem met relatief onervaren ontwikkelaars wordt aangepakt en anderzijds een situatie waarin het om een eenvoudig informatieprobleem gaat waarbij men ervaren ontwerpers kan inzetten. In deze (extreem) verschillende situaties treden veelal grote verschillen op qua werkwijze bij het modelleren, stappenplan of fasering bij het beheersen, teamsamenstelling met betrekking tot leren en veranderen etcetera. 34

Hoofdstuk 3 Om ontwikkelsituaties te kunnen inschatten zijn in literatuur en praktijk van het softwarevakgebied verschillende indelingen gemaakt van relevante situationele kenmerken. Situationele kenmerken worden daarin onderverdeeld naar bijvoorbeeld het type organisatie (voorbeelden van kenmerken zijn organisatiestructuur en -cultuur), het type applicatie (voorbeelden van kenmerken zijn complexiteit en omvang) en het type betrokkenen (voorbeelden van kenmerken zijn kennis en ervaring). Uitgangspunt voor het bepalen van een strategie is veelal het inschatten van de onzekerheid van een project, zie bijvoorbeeld (Wijnen, Renes en Storm 1987, de Haas en Wubbels 1990).

Methoden, technieken en gereedschappen zijn de elementen die concrete voorschriften en richtlijnen voor werkwijzen (onder andere stappenplannen en mijlpaalprodukten) en bijbehorende vormen van ondersteuning (onder andere gereedschappen) omvatten. In dit boek wordt slechts zijdelings gerefereerd aan geautomatiseerde gereedschappen.

Bezien we de literatuur van het informatiesystemen en softwarevakgebied dan blijkt dat de elementen van het kader door verschillende 'ontwikkelscholen' op verschillende manieren worden afgedekt en ingevuld. We lichten dit kort toe. Het werk van onder andere (Olie et al 1988) en (Lindgreen et al 1990) heeft een sterke ori~ntatie op de theorie van het modelleren. Hoewel belangrijke inzichten zijn opgeleverd, beperkt dit werk zich voornamelijk tot het analyseren en ontwerpen van informatiesystemen en de methoden en technieken die daarbij kunnen worden gebruikt Aan andere ontwikkelas-pecten als beheersen, leren en veranderen wordt vrijwel geen aandacht besteed. Dit geldt ook voor het element contingentietheorie. Avison en Wood-Harper (1990) en Mumford (1983) richten zich met name op de organisatorische en de sociale context van informatiesystemen. Verander- en leeraspecten worden sterk benadrukt. Het ontwikkelaspect beheersen krijgt slechts zijdelings aandacht. Ook door deze ontwikkelschool wordt vrijwel niet gerefereerd aan contingentietheorie. Belangrijke representanten van een derde ontwikkelschool waarin het ontwikkelaspect beheersen centraal staat zijn (Boehm 1988, Basili en Rombach 1988, Wijnen, Renes en Storm 1987). In de literatuur over dit aspectgebied wordt relatief weinig aandacht besteed aan modelleren, organisatieverandering en contingentietheorie. Het voorgaande overziend geldt dat geen van de genoemde scholen de essentie van het ontwikkelwerk het 'beste' benadert. Vanuit verschillende visies en filosofie~n worden verschillende bijdragen geleverd aan een zo volledig mogelijk beeld van informatiesysteemontwikkeling. Wel dienen vraagtekens te worden gezet bij enerzijds de relatief geringe aandacht voor contingentietheorie en anderzijds het vrijwel ontbreken van aandacht voor het ontwikkelaspect balanceren. Voor wat dit laatste betreft kan worden gesteld dat daarmee wordt voorbij gegaan aan een belangrijk facet van het ontwikkelwerk. Zoals elke ontwerpdiscipline heeft systeemontwikkeling vooral betrekking op het ontwerpen van alternatieven, het maken van afwegingen (balanceren) en het maken van keuzes tussen alternatieven (Simon 1960). Met name om die reden zal in dit hoofdstuk het ontwikkelaspect balanceren een belangrijke rol spelen bij de beschrijving van een samenhangend beeld van ontwikkelaspecten. Het element contingentietheorie speelt een rol in hoofdstuk 7

35

Naar een samenhangend beeld van het ontwikkelen van injonnatiesystemen wanneer een methode wordt ontwikkeld voor het specificeren van kwaliteitseisen. Zoals gesteld dient het samenhangend beeld in dit boek onder meer als referentiekader om het begrip kwaliteit op evenwichtige wijze te kunnen verankeren in de bestaande opvattingen van systeemontwikkeling. Daarmee kan onder andere worden voorkomen dat men bij het streven naar kwaliteitsverbeteringen op deelgebieden verkeerde verwachtingen koestert met betrekking tot het totale effect Verschillende empirische studies hebben inmiddels uitgewezen dat pogingen om de kwaliteit van het ontwikkelwerk te verbeteren veelal op een beperkt deelgebied (bijvoorbeeld in een enkele fase van de levenscyclus) effect sorteren en dat de effecten op de kwaliteit van het totale werk en de eindresultaten daarvan vooralsnog wisselend worden beoordeeld (Kusters en Wijers 1992, Stobart et al 1993).

3.3 Een samenhangend beeld van ontwikkelaspecten De ontwerpkunst en -kunde met betrekking tot informatiesystemen wordt tekort gedaan wanneer men zich geen rekenschap geeft van de verschillende ontwerpaspecten die deze discipline kenmerkt Het ontwikkelen van informatiesystemen is een multidisciplinaire activiteit waarin meerdere ontwikkelaspecten in samenhang dienen te worden beschouwd. In dit hoofdstuk geven we een nadere beschrijving van de vijf ontwikkelaspecten modelleren, beheersen, balanceren, leren en veranderen en hun onderlinge samenhang. De vijf ontwikkelaspecten worden in (Bemelmans 1990) aangeduid als clusters van ontwikkelactiviteiten (zie figuur 3.2).

Figuur 3.2: De vijf ontwikkelaspecten van systeemontwikkeling Deze ontwikkelaspecten werden reeds eerder beschreven in hoofdstuk 2 zodat we dat hier niet herhalen. Doel van bovenstaande figuur is om de verschillende soorten werkzaamheden bij het ontwikkelen van informatiesystemen te kunnen onderscheiden. Zoals gesteld hebben met name de onderlinge relaties en de samenhang tussen de vijf aspecten in litera-

36

Hoofdstuk 3 tuur en.pmktijk vooralsnog relatief weinig aandacht gekregen. Dit is echter wel een voorwaarde voor efficiënte en effectieve systeemontwikkeling. Om dit toe te lichten nemen we als voorbeeld de relatie tussen modelleren en beheersen. Om beheersactiviteiten als sturing en bewaking te kunnen verrichten, bijvoorbeeld met betrekking tot kwaliteit, dienen zij beschreven te worden in relatie tot modelleeractiviteiten. Immers wanneer men nauwelijks weet welk soort werk uitgevoerd moet worden kan men ook geen invulling geven aan de sturing van dat werk. en aan het bewerkstelligen van kwaliteit daarbinnen. In de volgende paragraaf wordt een nadere beschrijving gegeven van de vijf genoemde ontwikkelaspecten (lees: soorten werk). Voor elk ontwikkelaspect wordt kort teruggekoppeld naar de in het voorgaande hoofdstuk beschreven benaderingen van kwaliteit

3.3.1

ModeDeren en kwaliteit

Modelleren is het uitvoeren van iteratieslagen van telkens specificeren en realiseren, zie figuur 3.3 (Argelo, van Riel en Wintraecken 1990). Constraints, c.q. restricties, randvoorwaarden of beperkingsregels, voor het specificeren en realiseren kunnen van geheel verschillende aard zijn; bijvoorbeeld technisch inhoudelijk, beheersmatig, sociaal, organisatorisch, menselijk, etcetera.

I

specificeren!

I

I I

realiseren

constraints I

I

Figuur 3.3: Modelleren Specificeren en realiseren vinden telkens opnieuw plaats in elke fase van de levenscyclus van een informatiesysteem. Voorbeelden van fasen zijn informatieplanning, analyse en ontwerp, realisatie, invoering en beheer. Doel van modelleren is het ontwikkelen van de (inhoudelijke) structuur van een informatiesysteem. Centraal staan daarbij de structuuraspecten proces, data en gedrag (Olie et al 1988). Via een reeks van tussenprodokten van modelleeractiviteiten dient uiteindelijk een werkend informatiesysteem te ontstaan. Tussenprodokten zijn bijvoorbeeld bedrijfsprocesmodellen, datamodellen, dialoog- en programmastructuurmodellen. De uiteindelijke com-

37

Naar een samenhangend beeld van het ontwikkelen van informatiesystemen

ponenten van een informatiesysteem zijn de programmatuur, de database en kennisbase, de mens-machine-interface en de systeeminterface. Op grond van het voorgaande kan niet worden geconcludeerd dat hier sprake is van inzichtelijke en goed gestructureerde ontwikkelactiviteiten. Vaak worden in de praktijk van het ontwikkelwerk met name de modelleerconcepten proces, data en gedrag door de verschillende betrokkenen telkens op andere wijze geïnterpreteerd (Zachman 1987). Een redelijk helder ordeningskader voor proces-, data- en gedragsmodellen is beschreven door onder andere (Iivary 1989). Onderscheid wordt gemaakt tussen de structuuraspecten data, proces en gedrag op drie verschillende beschouwingsniveaus (zie figuur 3.4). Het onderscheid tussen een data- en procesaspect van een informatiesysteem is al jaren gemeengoed in de software-industrie. Het onderscheid tussen proces- en gedragsaspecten staat echter eerst sinds enige jaren in de belangstelling. Op grond van de toenemende complexiteit van informatiesystemen en de hogere eisen die door gebruikers worden gesteld aan bijvoorbeeld de responsesnelheid van een systeem wordt de beschrijving van het gedrag steeds belangrijker. Heeft het procesaspect betrekking op de verwerking van invoer naar uitvoer, het gedragsaspect heeft betrekking op het reageren van een informatiesysteem op het optreden van gebeurtenissen. Zowel externe gebeurtenissen (in de omgeving) van een informatiesysteem als de interne gebeurtenissen binnen een systeem zijn van belang. Een voorbeeld van een externe gebeurtenis is de binnenkomst van. een order of een bestelling waardoor verschillende verwerkingsprocessen worden aangestuurd. Een voorbeeld van een interne gebeurtenis is een melding die door een informatiesysteem zelf moet worden gegenereerd, bijvoorbeeld een melding over het ontstaan van inconsistenties in een gegevensbank.

data organisatie

informatieobjecten

conceptueel technologisch

databaseontwerp

proces

gedrag

bedrijfsfuncties informatieprocesmodel

bedriJfs"events"

programmaontwerp

gedragsmodel besturlngsontwerp

Figuur 3.4: Verschillende structuurmodellen De drie niveaus die in figuur 3.4 worden onderkend zijn aangeduid met successievelijk de

termen organisatie, conceptueel en technologisch. Over deze benamingen zijn reeds vele discussies gevoerd. Bijvoorbeeld wordt in de literatuur onderscheid gemaakt in niveau's van beschouwing met betrekking tot informatiesysteemcomponenten. Zo spreekt Langefors van een systelogisch, infologisch, datalogisch en technologisch niveau (Langefors 1980). Dietz daarentegen spreekt van een pragmatisch, semantisch, syntactisch en technisch niveau 38

Hoofdstuk 3

(Dietz 1987). Bedoeld wordt in beide gevallen dat men op verschillende manieren een informatiesysteemcomponent kan beschouwen al naar gelang het structuuraspect dat men wil benadrukken. Naast het onderscheiden van gegevensmodellen op verschillende niveaus kunnen ook procesmodellen en gedragsmodellen op verschillende niveaus worden beschreven. Wat betreft procesmodellen maakt figuur 3.4 onderscheid tussen bedrijfsfunctiemodelIen, informatieprocesmodellen en programmastructuurmodellen. In gedragsmodellen wordt aangegeven op welke wijze een organisatie of een informatiesysteem wordt aangestuurd of reageert op gebeurtenissen (events) van interne en externe herkomst. We lichten de verschillende niveaus kort toe. Gaandeweg een ontwikkeltraject kunnen verschillende tussenprodukten, c.q. beschrijvingen of modellen, worden gemaakt. Vaak staat in deze modellen één van de structuuraspecten proces, data en gedrag centraal, soms een combinatie daarvan. In de literatuur, onder andere Lindgreen (I 990) is het raamwerk gebruikt om de achterliggende concepten van de verschillende modelleeropvattingen ten opzichte van elkaar te positioneren en te vergelijken en om hun onderlinge relaties bespreekbaar te maken. Wanneer we deze beschouwingen over het modelleren terugkoppelen naar de kwaliteitsbenaderingen zoals beschreven in het voorgaande hoofdstuk 2, dan kunnen de volgende opmerkingen worden gemaakt. Van de kwaliteitsbenaderingen volgens respectievelijk Boehm en Cavano en McCall, ISO 9000, en TQM is binnen het modelleren de opvatting van eerstgenoemde auteurs van toepassing. Boehm en Cavano en McCall richten zich namelijk op het specificeren en realiseren van kwaliteitseisen. Voor wat betreft de kwaliteitsmodellen die worden gehanteerd door genoemde auteurs geldt dat deze zich met name richten op de vertaling van kwaliteitseisen van het conceptuele naar het technologische beschouwingsniveau (van kwaliteitsfactor naar kwaliteitsattribuut). Er wordt niet ingegaan op het specificeren van de binnen een bedrijfssituatie relevante kwaliteitseisen (het organisatiebeschouwingsniveau). Verder kan worden opgemerkt dat het omgaan met kwaliteit volgens genoemde auteurs voorbij gaat aan het onderscheid in deelprodokten (weergegeven door structuurmodellen) zoals genoemd in de bovenstaande figuur 3.4. De kwaliteitsfactoren worden weliswaar opgesplitst in kwaliteitsatrributen; deze worden echter niet verder vertaald naar deel- of tussenprodukten. In het vervolg van dit boek wordt nader ingegaan op het specificeren van kwaliteitseisen, met name in de hoofdstukken 5 en 7.

3.3.2

Beheersen en kwaliteit

Beheersen is het uitvoeren van iteratieslagen van telkens: stellen van (project)doelen; maken van (activiteiten en allocatie)plannen; laten uitvoeren van plannen; waarnemen en vergelijken (verifiëren en valideren), (van de resultaten van uitvoerende activiteiten); bijsturen ofwel modificeren (van zowel gestelde doelen als ontwikkelde plannen), (van Schaick 1985) (zie figuur 3.5). 39

Naar een samenhangend beeld van het ontwikkelen van informatiesystemen

Figuur 3.5: Beheersen

Doel van beheersen is het besturen en het controleren van het voortbrengingsproces. Beheersen wordt onderverdeeld naar vijf beheersaspecten, te weten het beheersen van tijd (faseren), het beheersen van geld (begroten), het beheersen van infonnatie, (documenteren), het beheersen van organisatie (organiseren) en het beheersen van kwaliteit (kwaliteitsborging en bewaking) (Wijnen, Renes en Stonn 1987) (zie figuur 3.6). '

Figuur 3.6: Verschillende beheersaspecten

40

Hoofdstuk 3 We geven een korte toelichting. Beheersen van tijd en geld heeft betrekking op het na elke fase nagaan in hoeverre het project binnen de gestelde tijd en binnen budget kan worden gerealiseerd. De beheersing van de (project)organisatie betreft de voortdurende toetsing op het functioneren van stuurgroep, projectgroep en werkgroepen zowel intern als in relatie met de omgeving. Beheersing van informatie betreft de voortdurende controle op de documentatie. Elk van de projectactiviteiten kan resulteren in documenten. Daarbij wordt onderscheid gemaakt in projectdocumentatie, productdocumentatie en ontwerpdocumentatie (Wijnen, Renes en Storm 1987). In de ontwerpdocumentatie worden de belangrijkste ontwerpbeslissingen vastgelegd die tijdens het ontwikkelingsproject tot stand zijn gekomen. Tenslotte de beheersing van kwaliteit. Hier gaat het om voortdurende aandacht voor de eisen die aan tussen- en eindresultaten zijn gesteld. Voortdurende aandacht dient te worden geoperationaliseerd in voorschriften en richtlijnen voor normstelling en toetsing van de kwaliteit. We merken op dat in literatuur en praktijk het beheersen van tijd, geld, organisatie en informatie het meest uitvoerig en concreet zijn uitgewerkt. Methoden voor het beheersen staan op grond daarvan ook wel bekend als methoden voor faseren en documenteren. Hoewel aanzetten zijn gedaan voor ondersteuning van het beheersaspect kwaliteit bestaan op dat gebied veel minder praktisch bruikbare concepten, methoden en technieken. Bij terugkoppeling van deze beschouwingen over het beheersen naar de kwaliteitsbenaderingen zoals beschreven in het voorgaande hoofdstuk 2, kunnen de volgende opmerkingen worden gemaakt. Van de kwaliteitsbenaderingen volgens respectievelijk Boehm en Cavano en McCall, ISO 9000, en TQM is binnen het beheersen met name de ISO-kwaliteitsbenadering van toepassing. De ISO-benadering van kwaliteit richt zich op kwaliteitsbeheersing door middel van het opstellen en hanteren van een verzameling richtlijnen en voorschriften. Naast het plannen en controleren van tijd, geld, informatie en organisatie dienen binnen het ontwikkelaspect beheersen specifieke kwaliteitsplannings- en -controle-activiteiten te worden onderscheiden. Kwaliteitsbeheersing volgens ISO richt zich enerzijds op de structurering en standaardisering van ontwikkelactiviteiten en anderzijds op de planning van specifieke kwaliteitscontrole-activiteiten zoals risico-analyses, produkt- en projectaudits. In het vervolg van dit boek wordt, na een nadere beschrijving van de kwaliteitsbenaderingen in hoofdstuk 4, in hoofdstuk 6 nader ingegaan op het beschrijven van voorschriften en richtlijnen voor ontwikkelactiviteiten.

3.3.3 Leren en veranderen en kwaUteit Leren en veranderen hebben betrekking op zeer vele (deel)aspecten van systeemontwikkeling die zowel van menselijke als organisatorische aard zijn. Bij menskundige aspecten kan men denken aan de instelling van ontwerpers ten aanzien van het ontwikkelwerk of de houding van gebruikers ten aanzien van een nieuw in te voeren informatiesysteem. Onbegrip en misinterpretatie bij ontwerpers en weerstanden bij gebruikers dienen tijdens het ontwikkelwerk tijdig onderkend te worden. Organisatie-aspecten die in dit verband een rol 41

Naar een samenhangend beeld van het ontwikkelen van informatiesystemen

kunnen spelen zijn bijvoorbeeld van bedrijfspolitieke aard, van interne en externe machtsverhoudingen of van bijvoorbeeld de groeifase waarin een organisatie zich bevindt. Verwaarlozing van dit soort aspecten betekent dat men geen oog heeft voor de essentiële groei- en leerprocessen waar informatiesysteemontwikkeling mee gepaard gaat Door de sociotechnische systeemliteratuur wordt een bijdrage geleverd aan de theorie van systeemontwikkeling. Duidelijk wordt gemaakt dat het ontwikkelwerk veel meer omvat dan alleen het technisch modelleren en construeren van een informatiesysteem of het beheersen van projecten. Met recht wordt gesteld dat leren en veranderen in hoge mate bepalend zijn voor de acceptatie en het succes van een informatiesysteem (Mumford 1983, Lundeberg 1982). In tegenstelling tot de ontwikkelaspecten modelleren en beheersen is het niet eenvoudig de kern van de ontwikkelaspecten leren en veranderen weer te geven. Om toch een beeld te geven van de aspecten leren en veranderen bespreken we kort een opvatting over informatiesysteemontwikkeling van (Hirshheim en Klein 1989). Deze auteurs stellen dat leren en veranderen sterk afhankelijk is van de wijze waarop ontwikkelaars (makers) en afnemers acteren en met elkaar omgaan bij de ontwikkeling van een informatiesysteem. Onderscheid wordt gemaakt tussen twee dimensies, te weten de dimensie objectief/subjectief en de dimensie orde/conflict (zie figuur 3.7).

orde technisch/ rationeel

afstemming/ communicatie

o b j e c t i e f - - - - - - - - - + - - - - - - - - - subjectief economisch/ politiek

conflict oplossend/ verbeterend conflict

Figuur 3.7: Verschillende manieren van acteren van ontwerpers bij het ontwikkelen van informatiesystemen Binnen de dimensie orde/conflict heeft orde de betekenis van wederzijds begrip en consensus. De term conflict staat voor wederzijds onbegrip. Conflict moet hier niet in een negatieve betekenis worden opgevat, bijvoorbeeld conflicten die ontstaan tussen partijen doordat zij elkaar moedwillig tegenwerken. Verschillende typen betrokkenen kunnen immers op basis van de verschillende posities die zij in een bedrijf innemen aan elkaar tegenstrijdige belangen hebben. Binnen de dimensie objectief/subjectief staat de term objectief voor eenduidig, rationeel en maakbaar. Daartegenover staat het begrip subjectief dat de verscheidenheid' in opvattingen 42

Hoofdstuk 3

van individuen representeert en dat overeenstemtDing door het sluiten van compromissen (intersubjectiviteit) als het hoogst haalbare beschouwt De aannamen en uitgangspunten van betrokkenen kunnen nu als volgt in de kwadranten van het raamwerk worden gepositioneerd. In het vlak objectiviteitlorde geldt de aanname dat het ontwikkelen van een informatiesysteem een puur inhoudelijk, technisch rationele aangelegenheid is. Het doel van systeemontwikkeling is van te voren bekend bij de betrokkenen en er kan recht toe recht aan naar een oplossing worden toegewerkt Het vlak subjectiviteitlorde representeert de opvatting dat informatiesysteemontwikkeling met name gericht is op het streven naar afstemming en communicatie. Uitgangspunt is dat probleemhebbers tezamen met ontwikkelaars streven naar systeemcompromissen waarmee eenieder gebaat is. Binnen het vlak objectief/conflict heerst de opvatting dat met name politieke, machts- en economische aspecten van doorslaggevende betekenis zijn voor systeemontwikkeling (qua type systeem, plaats in de organisatie etcetera). Betrokkenen beroepen zich bijvoorbeeld op hun posities en hun verantwoordelijkheden bij het bepalen van een keuze tussen conflicterende oplossingsrichtingen. Op het vlak subjectief/conflict geldt de opvatting dat systeemontwikkeling primair gericht is op het identificeren van problemen en het zoeken naar oplossingen voor onbegrip en weerstanden bij de betrokken partijen. Doel is niet zozeer het ontwikkelen van informatiesystemen als wel het ontstaan van wederzijds begrip en het verbeteren van de verstandhouding tussen de verschillende betrokken partijen of belangengroepen in de organisatie.

In de vier beschreven kwadranten verlopen leer- en veranderprocessen op verschillende manieren. In het kwadrant objectief/orde staat centraal de toename van (technische) kennis en vaardigheid van de ontwerper. In het kwadrant conflict oplossend/verbeterend ligt sterk het accent op het leren en veranderen van de organisatie waarbinnen een informatiesysteem wordt ontwikkeld.

In de sociotechnische literatuur over software en informatiesystemen werd tot voor kort relatief weinig aandacht besteed aan het begrip 'kwaliteit van systeemontwikkeling'. Hoewel 'kwaliteit zit in mensen' een veelgehoorde stelling is, wordt op het gebied van leren en veranderen, met name in vergelijking met de voorgaande kwaliteitsbenaderingen, vooralsnog niet uitvoerig ingegaan op het hanteerbaar maken van het begrip kwaliteit Zoals gesteld in hoofdstuk 2 wordt recent door verschillende auteurs gepoogd het begrip Total Quality Management (TQM) te introduceren bij informatiesysteemontwikkeling. Door TQM wordt sterk het accent gelegd op de mens, met name in samenwerkingsverbanden, als kwaliteitsbepalende factor bij produktontwikkeling. Met betrekking tot leren en veranderen (c.q. verbeteren) propageert TQM onder meer dat speciaal samengestelde (kwaliteits)groepen dienen te werken aan een continue verbetering van processen en produkten. Selectieve verbeteringsvoorstellen dienen bekrachtigd en geiinplementeerd te worden door het management. Zoals eerder gesteld is TQM gericht op een integrale aanpak van kwaliteitszorg en kwaliteitsverbetering waarin de mens centraal staat.

43

Naar een samenhangend beeld van het ontwikkelen van informatiesystemen In het voorgaande is kort beschreven wat de ontwikkelaspecten modelleren, beheersen en leren en veranderen inhouden. Ook is aangegeven welke benaderingen. van kwaliteit van toepassing zijn op elk van de beschreven aspectgebieden van het ontwikkelwerk. Onbesproken is gebleven het ontwikkelaspect balanceren. Zoals gesteld in paragraaf 3.2 heeft balanceren nog relatief weinig aandacht gekregen in de literatuur over software-ontwikkeling. In het vervolg van dit hoofdstuk richten we ons enerzijds op de betekenis van balanceren en anderzijds op de plaats van balanceren binnen een samenhangend model van ontwikkelaspecten.

3.3.4 Balanceren en kwaliteit Balanceren is een relatief onuitgewerkt begrip in de literatuur en praktijk van informatiesysteem- ontwikkeling. Balanceren heeft zoals gesteld betrekking op het bewerkstelligen van 'trade-off's' ofwel op het maken van afwegingen tussen verschillende ontwikkelaspecten. Om het begrip balanceren te verduidelijken onderscheiden we in deze paragraaf twee verschillende vormen van balanceren, te weten intern en extern balanceren. Met intern balanceren wordt een cluster activiteiten bedoeld dat betrekking heeft op het maken van afwegingen binnen het ontwikkelwerk. Daarentegen heeft extern balanceren betrekking op balanceeractiviteiten waarbij omgevings- of organisatie-aspecten een rol spelen. Om het onderscheid tussen intern en extern balanceren te verduidelijken gebruiken we voor extern balanceren de term integreren. De term integreren geeft aan dat het bij dit soort activiteiten gaat om zaken als invoering, inpassing of integratie van een informatiesysteem in een reeds bestaande organisatie. In het navolgende wordt gepoogd het intern en extern balanceren (integreren) te verduidelijken aan de hand van voorbeelden. In figuur 3.8 is het intern balanceren weergegeven als verbindend aspect tussen de overige ontwikke~aspecten.

l /

____"....

/

\

ba lanceren

Figuur 3.8 De plaats van (intern) balanceren De figuur moet als volgt geütterpreteerd worden. Intern balanceren kan enerzijds plaatsvinden tussen twee of drie verschillende ontwikkelaspecten en anderzijds bitmen elk van de

44

Hoofdstuk 3 ontwikkelaspecten afzonderlijk. We bespreken deze vonnen van intern balanceren achtereenvolgens aan de hand van voorbeelden.

lntem baltmeeren tUIBen ontwikkelaspecten - Balanceren tussen modelleren en beheersen Een voorbeeld van deze vonn van balanceren, dat zich in vrijwel ieder ontwikkelwerk voordoet, is het maken van afwegingen tussen enerzijds noodzakelijke en gewenste functionaliteit en anderzijds de tijd en kosten die daannee gemoeid zijn (Bemelmans 1991).

- Balanceren tussen modelleren en leren en veranderen Als voorbeeld van deze vonn van balanceren noemen we het binnen een project afstemmen van (fonnele) methoden en technieken op de kennis en de ervaring van het ontwikkelpersoneel. In de veelgeciteerde uitspraak (van een aantal jaren geleden) "de methode doet het niet" wordt voorgesteld om de bepaling van een methode niet alleen te baseren op inhoudelijke aspecten zoals bijvoorbeeld de moeilijkheidsgraad van een te ontwikkelen systeem of de onzekerheid met betrekking tot de behoeften van de afnemers. maar om veel gewicht toe te kennen aan leer- en verandereigenschappen van de mensen die het werk verrichten, c.q. de opgedane kennis, de verworven ervaring en het vakmanschap van het ontwikkelpersoneel (Van Rees 1984).

- Balanceren tussen beheersen en leren en veranderen Het concretiseren van leren en veranderen binnen ontwikkelprojecten kan plaatsvinden door projectervaringen tijdens een project periodiek en systematisch te bespreken met het oog op bijsturing en verbetering. Dit vergt extra inspanningen in tennen van discipline, tijd en kosten. Het moge duidelijk zijn dat deze extra inspanningen op het gebied van leren en en veranderen, afgewogen moeten worden tegen de overeengekomen doorlooptijd en het budget van het project (Basili en Rombach 1988).

lntem balanceren binnen aftonderlijke ontwikkelaspecten - Balanceren binnen het ontwikkelaspect modelleren Ontwerpers worden bij het realiseren van de specificaties van een infonnatiesysteem vaak geconfronteerd met een onderlinge beïnvloeding van de verschillende eisen. In dit verband is algemeen bekend (of berucht) de negatieve invloed die beveiligingsmaatregelen hebben op de responstijd binnen een infonnatiesysteem. Afhankelijk van de situatie zal de voorkeur aan meer of minder beveiliging dan wel meer of minder snelheid van het systeem moeten worden gegeven (Delen en Rijsenbrij 1990a, 1990b).

45

Naar een samenhangend beeld van het ontwikkelen van informatiesystemen - Balanceren binnen het ontwikkelaspect beheersen In de literatuur op het gebied van beheersen van infonnatiesysteemontwikkeling is de meest bekende vorm van balanceren het maken van afwegingen tussen enerzijds het inzetten van menskracht en anderzijds het binnen tijd en kosten blijven. Het betreft hier afwegingen tussen de beheersaspecten geld, organisatie en tijd. Daarbij dient .rekening te worden gehouden met onder andere de 'wet van Putnam' waarin wordt aangegeven dat meer menskracht toevoegen aan softwareprojecten slechts tot een bepaalde grens doorlooptijdverkorting betekent (Putnam 1974).

- Balanceren binnen de ontwikkelaspecten leren en veranderen Een actueel voorbeeld van balanceren binnen leren en veranderen zijn dè afwegingen die moeten worden gemaakt tussen de mate waarin wordt gestreefd naar hergebruik van eerder gedaan werk en de soort opleiding Oees: kennis en ervaring) van ontwikkelpersoneel dat daarvoor nodig is. In geval men streeft naar het ontwikkelen van herbruikbare componenten is andere kennis noodzakelijk (bijvoorbeeld met betrekking tot structureren en coderen) dan wanneer men zich beperkt tot het op 'informele' wijze hergebruiken van referentiemodellen van bedrijfssituaties (Biggerstaff en Perlis 1989).

Integreren (extern balanceren) Integreren heeft betrekking op balanceeractiviteiten die worden vetricht om het ontwikkelwerk en de resultaten daarvan af te stemmen op de omgeving (zie figuur 3.9).

Figuur 3.9 de plaats van integreren (extern balanceren) Met omgeving wordt hier bedoeld de organisatie waarin een informati~systeem moet worden ingepast. Om de externe gerichtheid van het integreren te illustreren is integreren in bovenstaande figuur aangegeven als een activiteitencluster tussen de ontwikkelomgeving 46

Hoofdstuk 3 van de makers en de organisatie-omgeving van de afnemers. We beschrijven kort drie voorbeelden van integreren waarbij we ons beperken tot de integratie-activiteiten tussen modelleren en de omgeving, beheersen en de omgeving en leren en veranderen en de omgeving. Omwille van de eenvoud en de duidelijkheid zien we af van het beschrijven van (complexere) voorbeelden van integratie-activiteiten waarbij meerdere ontwikkelaspecten een rol spelen.

- Integreren op het gebied van modelleren Afhankelijk van de mate waarin een informatiesysteem een maatwerk- dan wel een standaardapplicatie is dienen ontwikkelaars in samenwerking met gebruikers of opdrachtgevers interfaces van een informatiesysteem te specificeren en te realiseren. In geval het een maatwerksysteem betreft dat volledig moet zijn toegesneden op de bedrijfsvoering, zijn organisatiespecifieke interfaces noodzakelijk. Over het algemeen gaat dit ten koste van uitbreidings- en integratiemogelijkheden van het betreffende systeem. In geval van het ontwikkelen van standaardapplicaties geldt als uitgangspunt dat vanuit de omgeving, c.q. de organisatie, inspanningen moeten worden verricht voor wat betreft de aansluiting op een informatiesysteem.

- Integreren op het gebied van beheersen Op het gebied van beheersen kunnen afwegingen worden gemaakt tussen verschillende vormen van beheersing van het ontwikkelwerk. Door (Van Genuchten 1991) wordt onderscheid gemaakt tussen projectbeheersing, produktbeheersing en multiproduktbeheersing. Projectbeheersing omvat het ontwikkelwerk tot aan de oplevering van het produkt. In feite wordt het project(management) met name beoordeeld op het binnen de vastgestelde tijd en tegen de afgesproken kosten leveren van een produkt. Produktbeheersing gaat verder. Bij produktbeheersing draagt de ontwikkelorganisatie niet alleen de verantwoordelijkheid voor het op tijd en tegen aanvaardbare kosten afkomen van een project. Bij produktbeheersing wordt tevens verantwoordelijkheid gedragen voor het onderhoud en de evolutie van een informatiesysteem. Multiproduktbeheersing heeft betrekking op de beheersing van de ontwikkeling van een pakket van op elkaar aansluitende applicaties. Doel daarvan is dat elke nieuwe applicatie die wordt ontwikkeld en wordt ingevoerd in de organisatie naadloos aansluit op andere applicaties. Het moge duidelijk zijn dat de verschillende beheersvormen sterk verschillen voor wat betreft de wijze van organiseren, faseren, documenteren, begroten en het beheersen van de kwaliteit. Integreren heeft in dit verband betrekking op het bepalen van de beheersvorm die het beste aansluit bij de behoeften en de wensen van de betrokken organisatie.

- Integreren op het gebied van leren en veranderen Afhankelijk van het soort produkten dat makers leveren kunnen zich grote verschillen voordoen in vereiste kennis en ervaring, bijvoorbeeld op het gebied van programmeertalen of op het gebied van de communicatie tussen afnemers en makers. Voorbeeld: voor makers die zich richten op een anonieme markt en daarvoor standaardpakketten ontwikkelen is de 47

Naar een samenhangend beeld van het ontwikkelen van informatiesystemen communicatie met individuele klanten van ondergeschikt belang. Vaak wordt het inschatten van klantwensen door anderen gedaan en niet door de ontwikkelaars zelf. Daarentegen zijn ontwikkelaars die zich richten op specifieke applicaties eerder gebaat bij goede communicatievaardigheden (bijvoorbeeld met betrekking tot de invoering van een informatiesysteem) (frienekens en Thoma 1994).

3.4 Samenvatting en conclusies Het maken van afwegingen bij het bewerkstelligen van kwaliteit blijft vrijwel onvermeld in de benaderingen van kwaliteit volgens Boehm, Cavano en McCall en ISO 9000. De benadering van Boehm en Cavano en McCall gaan vrijwel niet in op het maken van afwegingen tussen de verschillende kwaliteitsfactoren die in een informatiesysteem kunnen worden ingebouwd. De IS0-9000-benadering gaat niet verder dan te stellen dat afhankelijk van een te ontwikkelen systeem een specifiek kwaliteitsplan moet worden gemaakt. In de TQM-benadering, die een integrale benadering van kwaliteit voorstaat en daarbij mens- en leer- en veranderaspecten centraal stelt, lijkt meer het accent te liggen op balanceren. Kwaliteitszorg- en verbetering is een taak van zowel management als ontwerpers. Bij het streven naar continue verbetering van prodokten en processen, onder andere middels 'teamwork', zal het balanceren een belangrijke plaats innemen. Uit de voorbeelden van de verschillende soorten van interne en externe ~alanceeractivitei­ ten moge duidelijk zijn geworden dat het maken van afwegingen in hoge mate bepalend is voor het slagen of falen van informatiesystemen. Kwaliteit van het proces van systeemontwikkeling en de prodokten of de resultaten daarvan (lees: software of informatiesystemen) zullen vrijwel altijd afhankelijk zijn van het vinden van een juiste balans tussen inspanningen binnen de verschillende ontwikkelaspecten. In de terminologie van Garvin wordt dit 'value based' kwaliteit genoemd. Zoals gesteld in hoofdstuk 2 is dit een van de soorten definities van Garvin die tot nu toe in de literatuur van het softwarevakgebied niet of nauwelijks aan de orde is gekomen. In dit hoofdstuk is vanuit een bedrijfskundige optiek een samenhangend beeld van systeemontwikkeling geschetst. Vanuit een algemeen kader van systeemontwikkeling en bekende stromingen in de informatiesystemenwereld zijn de ontwikkelaspecten modelleren, beheersen en leren en veranderen beschreven. Het ontwikkelaspect balanceren, dat aan de hand van voorbeelden is toegelicht, verduidelijkt de samenhang tussen de genoemde ontwikkelaspecten. Nadat in dit hoofdstuk het ontwikkelen van informatiesystemen en softwareprodokten centraal heeft gestaan, gaan we in hoofdstuk 4 nader in op de verschillen~ soorten kwaliteitsopvattingen. Het in dit hoofdstuk ontwikkelde model van ontwikkelaspecten dient daarbij als referentiekader. In hoofdstuk 4 wordt het ordenende werk van dit boek grotendeels afgesloten en worden richtingen uitgezet waarlangs naar kwaliteitsverbetering wordt gestreefd.

48

4

KWALITEITSOPVATTINGEN: WAT, Wm EN HOE

4.1 Inleiding Een veelgehoorde uitspraak is dat kwaliteit betrekking heeft op alle aspecten en componenten van een produkt en de wijze waarop dat wordt ontwikkeld. Vervolgens blijft onduidelijk welke aspecten en componenten worden bedoeld en wat kwaliteit daarvan betekent. In hoofdstuk 3 is een eerste stap gedaan om meer duidelijkheid te geven voor wat de prodokten en processen van informatiesysteemontwikkeling. Vijf ontwikkelaspecten (lees: clusters van activiteiten) werden in een samenhangend model beschreven. Om zicht te krijgen op de betekenis van kwaliteit zijn enkele bekende benaderingen van kwaliteit in relatie tot dat model kort besproken. Aangegeven is dat er met betrekking tot kwaliteit binnen systeemontwikkeling een aantal probleemgebieden bestaat. Omgaan met kwaliteit bij het ontwikkelen van informatiesystemen staat pas sinds kort volop in de belangstelling. Genoemd is reeds in dit boek de geringe aandacht voor de afnemer (user based kwaliteit), zeker gezien het toenemend belang van klantgerichtheid in de software-industrie, en het vrijwel ontbreken van aandacht voor het balanceren (value based kwaliteit). Daarnaast roept de toepasbaarheid van de kwaliteitsbenaderingen vragen op. Bijvoorbeeld is niet duidelijk op welke 'dingen' kwaliteit precies betrekking heeft. Zijn dat alleen eindprodukten, worden ook deel- of tussenprodokten bedoeld, of zijn het met name de processen waarvan de kwaliteit vastgesteld moet worden? Onduidelijk blijft ook welke personen verantwoordelijk zijn, ondersteunend zijn of daadwerkelijk betrokken zijn bij het bewerkstelligen van kwaliteit. Is dit met name een zaak van ontwerpers, speelt projectmanagement daarbij een rol, of zijn het juist afnemers van informatiesystemen die dienen te participeren in het ontwikkelwerk? Kortom: veel vragen en onduidelijkheden. Zolang deze vragen niet afdoende zijn beantwoord blijft omgaan met kwaliteit een vage aangelegenheid. Het daadwerkelijk hanteerbaar maken van kwaliteit en kwaliteitsbeheersing, in termen van het gezegde 'meten is weten', blijft dan ver verwijderd van de dagelijkse praktijk van het ontwikkelwerk. In dit hoofdstuk wordt in paragraaf 4.2 nader ingegaan op de in hoofdstuk 2 geïntroduceerde benaderingen van kwaliteit. Drie typen kwaliteitsopvattingen worden onderscheiden. Een nadere beschrijving vindt plaats vanuit de invalshoeken Wat, Wie en Hoe. Elk type kwaliteitsopvatting wordt gepositioneerd in het model van ontwikkelaspecten uit hoofdstuk 3. Tekortkomingen worden besproken. Paragraaf 4.3 gaat vervolgens nader in op de 'dingen' ofwel de objecten die in de verschillende kwaliteitsopvattingen centraal staan. Paragraaf 4.4 sluit dit hoofdstuk af met een samenvatting en enkele conclusies.

49

Kwaliteitsopvattingen: wat, wie en hoe

4.2 Drie typen kwaliteitsopvattingen: Wat, Wie en Hoe De in hoofdstuk 2 kort geïntroduceerde benaderingen van kwaliteit typeren we hier respectievelijk als volgt: "kwaliteit wordt bewerkstelligd door een verzameling kenmerken in een produkt aan te brengen"; afgekort met "Produktopvatting" "kwaliteit wordt bewerkstelligd door standaards en procedures na te leven"; afgekort met "Procesopvatting" "kwaliteit wordt bewerkstelligd door het nastreven van een contintJe verbetering van produkten, processen en middelen"; afgekort met de "Integrale opvatting" Tot de eerste soort opvattingen behoren de (hiërarchische) verzamelingen kwaliteitsattributen volgens bijvoorbeeld Boehm. De internationale standaards voor kwaliteitszorg volgens de IS0-9000-serie zijn representanten van de tweede soort opvatting. De omschrijving van de derde soort opvatting kan worden beschouwd als het kernpunt van Tdtal Quality Management (TQM). In de integrale aanpak van kwaliteitszorg zoals die door TQM wordt nagestreefd vormen samenwerkingsaspecten (bijvoorbeeld groepscomm)lnicatie) een belangrijke voorwaarde voor het bewerkstelligen van produkt- en proceskwaliteit We beschrijven elk van deze opvattingen vanuit de volgende invalshoeken: Wat is het object van kwaliteit ? Wie bepaalt kwaliteit (of: vanuit welk perspectief wordt kwaliteit nagestreefd) ? Hoe tracht men kwaliteit te bewerkstelligen ?

4.2.1 De Produktopvatting Door verschillende auteurs is het afgelopen decennium voortgebouwd op de in hoofdstuk 2 geïntroduceerde benaderingen van kwaliteit van (Boehm et al 1978) en (Cavano en McCall 1978). Genoemd kunnen worden (Willmer 1985, Deutsch en Willis 1987, Bemelmans 1991, Delen, Kouwenhoven en Rijsenbrij 1991). Zoals zal blijken uit de navolgende beschrijvingen wordt gestreefd naar een betere aansluiting bij de praktijk. We bespreken respectievelijk de opvattingen van (Willmer 1985) en vervolgens (Bemelmans 1991, Delen, Kouwenhoven en Rijsenbrij 1991). Evenals in hoofdstuk 2 gaan we niet gedetailleerd in op de betekenis van de afzonderlijke kwaliteitsfactoren, -attributen etcetera. ·Doelstelling van deze paragraaf is immers een ordening in de verschillende typen kwaliteitsopvattingen te brengen en de belangrijkste beperkingen te identificeren.

50

Hoofdstuk 4 De kwaliteitsopvatting volgens (Willmer 1985)

Willmer (1985) gaat een stap verder dan de in hoofdstuk 2 genoemde benaderingen van Boehm en Cavano en McCall. Willmer tracht in een model aan te geven op welke wijze kwaliteitskenmerken van software zijn gerelateerd aan de kenmerken die ontwerpers in een produkt kunnen aanbrengen (zie figuur 4.1 ). Wat is het object van kwaliteit? Bij Willmer is het object van kwaliteit een softwareprodukt De twee verzamelingen kenmerken die worden onderscheiden hebben respectievelijk betrekking op de kenmerken van een softwareprodukt die voor een afnemer de kwaliteit bepalen en de (interne) kenmerken van een softwareprodukt zoals die tijdens het ontwikkelproces kunnen worden ingebouwd. Doel van dit onderscheid is dat duidelijkheid ontstaat over de verschillende soorten begrippen en hun onderlinge relaties. Nogmaals moet worden benadrukt dat het in deze kwaliteitsopvatting gaat om de kwaliteit van eindprodukten. Er wordt geen (expliciet) onderscheid gemaakt in kwaliteitskenmerken van deel- of tussenprodukten zoals bijvoorbeeld datamodellen, programmatuur, soort documentatie etcetera. - taaiQellrulk ( dwdehjke naamgevii3'. lengte Zinnen, ~ullc GOTO, enz.

prodUkt· kenmerken makers

1

kwallteltskenmerken afnemers

• controle mogelijk eden In software ecoess/control ·mate van standaerdiSatle - mate van structurering - doetmentatle ~

• visualisering

---".

• beg' IJltlaarheld

- veral'lderllllllrheld -~eráu~held~a~e~~

• ~I'Kll.dla8rheld : ·te lcoppelen met andere software

• mogeliJkheld van hergebruk • testbllllrhe id ·efficiency van de software

• bevelllglno/!lutorlsatte gebrullr: • correctheldlvrll van fouten · gevoeligheld voor fouten • herstartbaarheld na fout~treden

x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x

~m=

Figuur 4.1: Kwaliteitskenmerken en produktkenmerken (Willmer 1985)

51

Kwaliteitsopvattingen: wat, wie en hoe Wie bepaalt kwaliteit ? Kennelijk dienen twee aparte (hoofd)groepen betrokkenen te worden onderkend: makers en afnemers. Afnemers specificeren kwaliteitskenmerken. Makers realiseren produktkenmerken. Op de horizontale as in figuur 4.1 zijn produktkenmerken in de taal van ontwerpers weergegeven (bijvoorbeeld taalgebruik in de software en mate van structurering). Op de verticale as staan de kwaliteitskenmerken in de taal van de afnemers, bijvoorbeeld: begrijpbaarheid, te koppelen met andere software en herstartbaarheid na foutoptreden. Hoewel beide typen kenmerken ook zijn terug te vinden in de benadering van Boehm en Cavano en McCall wordt daar geen expliciet onderscheid gemaakt tussen twee aparte venameiingen betrokkenen. Willmer's model kan worden beschouwd als een aanzet om de twee werelden van makers en afnemers nadrukkelijk te onderscheiden en tevens als een bijdrage aan de verbetering van de communicatie tussen makers en afnemers. Hoe wordt kwaliteit bewerkstelligd ? Willmer zet zich sterk af tegen het top-down (hiërarchisch) afleiden van produktkenmerken uit geaggregeerde kwaliteitkenmerken zoals dat door bijvoorbeeld Boehnl wordt beschreven. Door een netwerk van relaties (n:m) te beschrijven tussen twee aparte verzamelingen wordt de vertaling van kenmerken uit de ene naar de andere verzameling ondersteund. Uiteraard spelen hierbij vele randvoorwaarden (organisatorisch, functioneel, technisch) een rol Bijvoorbeeld de standaardisatie die een ontwerper wenst te hanteren moet afgestemd worden op de geldende standaards in de organisatie; de mogelijkheden vpor visualisering (grafische weergave-mogelijkheden, kleuren en geluid) hangen vaak samen met de mogelijkheden van de technologie waarover men beschikt.

De kwaliteitsopvatting volgens (Bemelmans 1991, Delen, Kouwenhoven en Rijsenbrij 1991) Wat is het object van kwaliteit?

In deze kwaliteitsopvatting worden vier groepen kwaliteitskenmerken oqderscheiden die kwaliteitseisen worden genoemd. Naast de eisen die kunnen worden gesteld aan het proces (het ontwikkelwerk) wordt respectievelijk onderscheid gemaakt tussen gebruikseisen en beheerseisen van een systeem en eisen met betrekking tot het produkt infonnatie (zie figuur 4.2). We beperken ons hier tot de eisen die betrekking hebben op een produkt (c.q. informatie en informatiesysteem). Het onderscheid tussen gebruikseisen en beheerseisen komt in grote lijnen overeen met het onderscheid tussen groepen kwaliteitskenmerken in de eerder genoemde opvattingen van Boehm ('huidige nuttigheid' versus 'onderhm,tdbaarheid', zie hoofdstuk 2) en Cavano en McCall ('produktgebruik' versus 'produktrevisie', zie hoofdstuk 2). Belangrijk verschil vormt echter de aparte groep kwaliteitseisen met betrekking tot het 'produkt' informatie. Hiermee wordt getracht de perceptie van gebruikers van de kwaliteit van de informatie die door een informatiesysteem wordt verstrekt in ~nmerken uit te drukken. Delen en Rijsenbrij stellen dat de rol die de informatie in het bedrijf speelt, bepalend is voor alle andere eisen.

52

Hoofdstuk4 Wie bepaalt kwaliteit ? systeemeisen

eisen voor het produkt 'informatie·

-juistheid - volledigheld - actualiteit - controleerbaarheld - nauwkell'igheid - aggregatie -selectie

gebrulkseisen - tijdigheld - integriteit -juistheid -volledigheid - betrouwbaarheld secll'ltylbeveillglng doelmatigheld - effectiviteit - gebruiJ(svriendelljlcheid

beheerseisen • flexibiliteit - onderhoudbaarheld - testbaarheld -portabiliteit - inpasbaarheld in de technische Infrastructuur -herbruikbaarheid

I

Figuur 4.2: Kwaliteitseisen vanuit drie invalshoeken (Beme1mans 1991) De kwaliteitseisen met betrekking tot informatie, die de waarde van informatie voor een organisatie representeren, zijn sterk context~ en organisatiegebonden (van Kesse1199l).

Dit houdt in dat deze eisen alleen op intersubjectieve wijze zijn vast te stellen, dat wil zeggen in onderling overleg tussen mensen die gebruik maken van informatie. Verder wordt in deze kwaliteitsopvatting, nadrukkelijker dan in voorgaande opvattingen, qua systeemeisen onderscheid gemaakt tussen gebruikseisen en beheerseisen. Gepoogd wordt op deze manier aansluiting te vinden bij de afnemers die de eisen dienen af te leiden, te specificeren en bovenal af te wegen. In die zin is deze kwaliteitsopvatting meer dan de voorgaande opvattingen, verwant met de user based defmities van Garvin. Hoe wordt kwaliteit bewerkstelligd ?

Op het punt van het realiseren van produktkwaliteit komt deze opvatting in grote lijnen overeen met voorgaande opvattingen, namelijk kwaliteitseisen worden vertaald in produkt~ kenmerken. Delen en Rijsenbrij beschrijven een werkwijze om deze vertaalslagen uit te voeren. Bemelmans richt zich met name op het 'voortraject' ofwel op het afleiden van kwaliteitseisen uit besturingskarakteristieken van een organisatie. Gesteld wordt dat kwali~ teitseisen in tegenstelling tot functionele eisen in mindere mate verschillen per specifieke (bedrijfs)situatie. Karakteristieken van het generieke type besturingssituatie dienen als basis voor het afleiden van typen informatiesystemen en de daarbij relevante kwaliteitseisen. Ook op deze opvatting komen we terug in hoofdstuk 7 waar het proces van het specifice~ ren en realiseren van kwaliteitseisen centraal staat

53

Kwaliteitsopvattingen: wat, wie en hoe Conclusies In dit type kwaliteitsopvatting ligt de nadruk ligt op het specificeren en realiseren van kwaliteitseisen (van analyse naar ontwerp en bouw). In het ontwikkelaspectenmodel, zie hoofdstuk 3, valt dit type kwaliteitsopvatting binnen het aspect modelleren. Er wordt vrijwel niet gerefereerd aan de ontwikkelaspecten beheersen, leren, veranderen en balanceren. Tegen de achtergrond van het ontwikkelaspect modelleren kunnen met betrekking tot dit type kwaliteitsopvatting de volgende opmerkingen worden gemaakt:

kwaliteitseisen hebben alleen betrekking op eindprodukten. Er is geen eensluidende opvatting over wat met een produkt wordt bedoeld, afwisselend gaat het om het 'produkt' informatie, een informatiesysteem of een softwareprodukt. Tussen- en deelprodukten worden niet genoemd; de afnemer van softwareprodukten wordt nadrukkelijker onderkend als betrokken partij dan in de kwaliteitsopvattingen van dit type die eerder in hoofdstuk 2 werden beschreven; bijvoorbeeld: door Willmer wordt onderscheid gemaakt in aparte verzamelingen kwaliteitsfactoren voor respectievelijk afnemers en voor makers; door Bemelmans wordt gewezen op het belang van het afleiden van kwaliteitseisen uit de kenmerken van een (besturingssituatie); door Delen en Rijsenbrij en door Sernelmans wordt een aparte groep kwaliteitseisen onderscheiden met betrekking tot het produkt informatie.

4.2.2 De Procesopvatting In hoofdstuk 2 hebben we ons, voor wat dit type opvatting betreft, beperkt tot een korte introductie van de ISO 9000 standaards. Kwaliteit dient in deze opvatting te worden nagestreefd door de voortbrengings- of produktieprocessen binnen organisaties te defmiëren en te structureren. Aangetoond moet kunnen worden dat het proces iets oplevert dat aan gestelde nonnen voldoet. In deze paragraaf gaan we nader in op de betekenis van deze standaards voor de software-industrie. Recent zijn voor de software industrie richtlijnen verschenen die de toepassing van ISO 9001 mogelijk maken in de software-industrie (ISO 9000-3 1991). We bespreken de ISO kwaliteitsopvatting vanuit de invalshoeken Wat, Wie en Hoe.

Wat is het object van kwaliteit? De ISO-opvatting is gericht op richtlijnen en voorschriften voor het 'ontwikkelen van software. Met betrekking tot de voortbrengingsprocessen in de software-industrie wordt een driedeling gehanteerd. ISO 9000-3 is als volgt gestructureerd. Er wordt onderscheid gemaakt tussen voorschriften en richtlijnen voor respectievelijk het opzetteil van een raamwerk voor een kwaliteitssysteem, het opstellen van procedures voor de 1evenscyclus-activi-

54

Hoofdstuk 4 teiten en het opstellen van procedures voor de ondersteunende activiteiten rondom het ontwikkelwerk (zie figuur 4.3). We geven een korte toelichting bij deze structuur.

-Het raamwerk van een kwaliteitssysteem Het raamwerk heeft betrekking op de organisatie-aspecten van een kwaliteitssysteem. Het betreft onder andere de verantwoordelijkheden en bevoegdheden van de verschillende betrokken partijen bij het opstellen en naleven van procedures. Voorschriften en richtlijnen hebben verder betrekking op: het formuleren van kwaliteitsbeleid en het vastleggen van verantwoordelijkheden en bevoegdheden van personen die te maken hebben met kwaliteit het opzetten van een kwaliteitssysteem dat is geïntegreerd in de organisatie regelmatige controle van een kwaliteitssysteem en aanpassing en bijstelling van een kwaliteitssysteem op grond van ervaringen: kwaliteitsborging ISO 9000-3 Raamwerk

Activiteiten tijdens levenscyclus Ondersteunende activiteiten

Verantwoordelijkheid van het Management

Contract Review

Configuratie Management

Kwaliteitssysteem

Specificatie van de behoeften van de Inkoper

Document Beheersing

Intern Kwaliteitssysteem

Ontwikkelingsplannlng

Kwaliteitsdossiers

Kwalliteltsplannlng

Metrieken

Ontwerp en Implementatie

Regels en Conventies

Testen en Vrijgave

Gereedschappen en Technieken

Audit Corrigerende acties Acceptatie Inkoop Onderhoud Scholing, Training i

I Figuur 4.3: Structuur van ISO 900()...3

- Levenscyclus-activiteiten In het tweede deel van ISO 9000-3 staat de levenscyclus van een software-ontwikkelproject centraal. Nadrukkelijk wordt gesteld dat het niet de bedoeling is dat een 'standaard' levens-

55

Kwaliteitsopvattingen: wat, wie en hoe cyclusmodel gehanteerd dient te worden. Afhankelijk van de karakteristieken van een project kan een alternatief of aangepast model als uitgangspunt worden genomen. Daarbinnen dienen vervolgens zogeheten 'kwaliteitgerichte' activiteiten te worden gedefmieerd en gestandaardiseerd. Het gaat dan om procedures voor onder andere: het opstellen en beoordelen van contracten het defmitsren van inkoopeisen het opstellen van een ontwikkelplan (onder andere documentatie, mijlpalen) het opstellen van een projectspecifiek kwaliteitsplan (onder andere reviews, inspecties) het ontwerpen en implementeren alsmede testen en valideren de acceptatie, invoering en onderhoud van softwareprodokten

- Ondersteunende activiteiten In dit deel van de norm gaat het om niet-projectgebonden activiteiten. Voorschriften hebben betrekking op het opstellen van kwaliteitsgerichte procedures voor

on~er

andere:

het onderscheid tussen verschillende versies van de softwareprodokten alsmede het plannen, doorvoeren en controleren van veranderingen in softwareprodokten (configuratiemanagement) het plannen en bewaken van documenten het hanteren van metrieken het organiseren van opleidingen Het bovenstaande geeft een beeld van de omvang en de verscheidenheid van de procedures die men dient op te stellen volgens ISO 9000-3. Duidelijk is de sterk 'procedurele, c.q. procesgeoritsnteerde benadering van kwaliteit. Wie bepaalt kwaliteit ? Hoewel geen specifreke functies of taakgebieden worden gedefmieerd binnen ISO 9000-3 blijkt uit de beschrijving van de richtlijnen duidelijk de betrokkenheid van twee soorten partijen, te weten het algemeen management en het projectmanagement (van het ontwikkelwerk). Het formuleren van kwaliteitsbeleid en het opzetten en beheren van kwaliteitssystemen valt onder de verantwoordelijkheid van het algemeen (kwaliteits)management. Het hanteren van een kwaliteitssysteem, respectievelijk het maken van projectspecifieke kwaliteitsplannen (onder andere kwaliteitscontrole-activiteiten, het toepassen van metrieken etcetera) valt onder het takenpakket van het projectmanagement. Aan de ~trokkenheid van opdrachtgevers, gebruikers en beheerders van informatiesystemen wordt slechts zijdelings gerefereerd.

56

Hoofdstuk 4

Hoe wordt kwaliteit bewerkstelligd ? Een van de kernbegrippen bij het opzetten en hanteren van kwaliteitssystemen is het begrip kwaliteitscontrole. Controles kunnen gericht zijn op het aantal fouten in tussen- of deelprodokten maar ook op het aantal fouten dat wordt gemaakt tegen ontwerpprincipes (bijvoorbeeld gestructureerd ontwerpen, modulaire decompositie, 'information hiding'), de inspanningen die worden gestoken in een bepaald (deel)ontwerp, het al dan niet voldoen aan ontwerpstandaards etcetera. De controle-activiteit die in ISO 9000-3 het meest nadrukkelijk wordt genoemd, is testen. Testen kan worden opgevat als het zoeken van fouten in een produkt en het herstellen van die fouten (van Vliet 1993). Naast aspecten van het opzetten van een testplan worden in ISO 9000-3 aspecten van het uitvoeren van een test beschreven. Genoemd worden het verifiëren van een produkt (wordt het produkt op de juiste wijze ontwikkeld ?) en het valideren van een produkt (wordt het juiste produkt ontwikkeld ?). Daarnaast worden enkele aspecten genoemd van het testen van een produkt in een bedrijfssituatie (bijvoorbeeld de specifieke verantwoordelijkheden van afnemer en maker voor het uitvoeren van een test). Testen is geen garantie voor kwaliteit. Testen kan wel de aanwezigheid van fouten aantonen, echter niet hun afwezigheid. Daarom wordt verwezen naar aanvullende controletechnieken die in de loop der jaren zijn ontwikkeld. Genoemd worden respectievelijk 'Structured Walk-throughs' van (Yourdon 1985) en 'Fagan's Inspections' van (Fagan 1986). Beide methoden richten zich op het controleren van tussen- of deelprodokten in eerdere fasen van de levenscyclus dan de fasen programmeren en coderen. Conclusies ISO 9000-3 geeft richtlijnen en voorschriften voor het plannen en controleren van kwaliteit tijdens het voortbrengingsproces van software. Het opstellen en het navolgen van deze procedures is een taak van respectievelijk het algemeen management en het projectmanagement. Slechts zijdelings wordt in deze kwaliteitsopvatting gerefereerd aan de ontwikkelaspecten modelleren, leren, veranderen en balanceren. Duidelijk is daarmee dat deze kwaliteitsstandaard binnen het ontwikkelaspect beheersen valt van het in hoofdstuk 3 beschreven systeemontwikkelmodel. Tegen de achtergrond van het ontwikkelaspectenmodel maken we de volgende opmerkingen: ISO 9000-3 heeft betrekking op het opstellen van procedures voor het controleren van de kwaliteit van het software-ontwikkelwerk. De beschrijving van ontwikkelprocessen gaat niet verder dan een algemeen kader voor de levenscyclus, er wordt niet aangegeven welke kwaliteitseisen aan welke processen kunnen worden gesteld; ISO 9000-3 is niet bestemd voor de afnemers van softwareprodukten. Afnemers zijn niet direct betrokken bij het formuleren van een kwaliteitsbeleid en het opzetten en borgen van kwaliteitssystemen die betrekking hebben op het voortbrengingsproces. Indirect kunnen afnemers wel een rol spelen, bijvoorbeeld 57

Kwaliteitsopvattingen: wat, wie en hoe wanneer zij voorwaarden stellen aan makers met betrekking tot de certificatie van kwaliteitssystemen.

4.2.3 De Integrale opvatting Zoals gesteld in hoofdstuk 2 is een van de centrale stellingen van de 'Total Quality Management' -beweging het streven naar permanente kwàliteitsverbetering (Oakland 1989). In deze opvatting wordt kwaliteit met name bewerkstelligd door mensen binnen samenwerkingsverbanden. Daarmee kiest TQM voor een andere benadering dan kwantitatieve metingen aan eindprodukten (vergelijk Boehm et al 1987) of standaardisatie-exercities (vergelijk ISO 9000-3 1991). Omdat de TQM-opvattingen langzaam maar zeker terrein winnen binnen de software-industrie bespreken we ook deze opvatting vanuit de invalshoeken Wat, Wie en Hoe. Wat is het object van kwaliteit? TQM kiest een andere benadering dan uitsluitend een eenzijdige produkt- of een eenzijdige procesoriëntatie binnen het kwaliteitsdenken (zie onder andere (Boddendijk 1992)). Een belangrijk aandachtsgebied betreft de samenwerking tussen mensen ('teamwork') en het verbeteren van de relaties tussen mensen en tussen mensen -en de procesvoering. Met name 'teamwork' -concepten voor de wijze van organiseren van groepswerk en het communiceren binnen groepen van samenwerkenden worden binnen TQM sterk benadrukt. In de TQM-driehoek van (Oakland 1989) worden de kernbegrippen van TQM, te weten managementbetrokkenheid, 'teamwork' en procesbewaking weergegeven (zie figuur 4.4).

Managementbetrokl:enheid

Procesbewaking

"T eamworl:"

Figuur 4.4: de TQM driehoek.

58

Hoofdstuk 4 Wie bepaalt kwaliteit ? Uit de figuur blijkt dat TQM voor wat betreft de betrokkenen bij het voortbrengingsproces met name onderscheid maakt tussen management en samenwerkingsverbanden. Het hoger management speelt een belangrijke rol bij het bekrachtigen en implementeren van de verbeteringsvoorstellen die vanuit groepswerk 'naar boven komen'. Hoe wordt kwaliteit bewerkstelligd ? Zoals gezegd zijn de speciale samenwerkingsverbanden de belangrijkste bron van kwaliteitsverbetering. Binnen samenwerkingsverbanden wordt periodiek en selectief procesonderzoek verricht Nadrukkelijk wordt gesteld dat procesonderzoek niet gericht mag zijn op eenzijdige verbetering, optimalisering of perfectionering van geisoleerde procedures. Een bekend voorbeeld is de IBM 'Cleanroom' -methode die zich met name richt op de organisatie van de samenwerking. Voorop staat hierbij dat het team een gemeenschappelijk doel heeft, dat binnen het team volledig sanctievrij wordt gewerkt en dat het team als eenheid op het eindprodukt kan worden aangesproken. Een ander kenmerk van de IBM 'Cleanroom'-methode is dat het ontwikkelaars niet is toegestaan eigen deelprodokten of tussenprodokten op eigen initiatief te vertalen naar een volgende fase, bijvoorbeeld van specificaties naar ontwerp, of van ontwerp naar programmatuur en code. Dit moet voorkomen dat ontwikkelaars niet-overdraagbare en alleen voor zich zelf begrijpelijke constructies ontwerpen, die vervolgens moeilijk te onderhouden en uit te breiden zijn. Een ander soort methode dat door TQM wordt gepropageerd heeft betrekking op het identificeren van de belangrijkste wensen en behoeften van afnemers. Ook hier staat teamwork centraal. De nadruk wordt gelegd op de participatie van de klant of de afnemer in samenwerkingsverbanden. Een voorbeeld van dit soort methoden is Quality Function Deployment (QFD)-methode (Hauser en Clausing 1988). We komen uitvoeriger terug op deze methode in hoofdstuk 7. Samenvatting In de TQM-opvattingen ligt het accent sterk op het organiseren van samenwerkingsverbanden waarbinnen kwaliteitsverbetering wordt nagestreefd. Getracht wordt te voorkomen dat het accent bij kwaliteitszorg eenzijdig ligt op de kwaliteit van prodokten of de kwaliteit van processen. In een integrale benadering van kwaliteit dienen zowel produkten, processen als middelen (mensen) een rol te spelen. TQM is zoals gesteld (nog) niet volledig toegesneden op de software-industrie. Op grond van de bovenstaande beschrijvingen van de drie verschillende typen kwaliteitsop-

vattingen vatten we een en ander samen in drie hoofd-conclusies.

Eerste conclusie hangt samen met de Wat-vraag. Duidelijk is dat typen kwaliteitsopvattingen betrekking hebben op verschillende objecten van kwaliteit In de opvatting van onder andere (Willmer 1985, Bemelmans 1991, Delen, Kouwenhoven en Rijsenbrij 1991) zijn dit de (software)produkten. In de ISO 9000-3 opvatting zijn dit de processen en de procedures, 59

Kwaliteitsopvattingen: wat, wie en hoe en in de TQM-opvatting zijn dit naast de prodokten en de processen de middelen (met name de mensen) en de samenwerkingsverbanden. Belangrijke beperkingen zijn: met betrekking tot produkten: de onduidelijkheid omtrent de betekenis van een produkt (bijvoorbeeld: 'informatie', informatiesysteem, software-, deel- en eindprodukten) met betrekking tot processen: de onduidelijkheid omtrent de verschillende soorten processen die moeten worden onderscheiden (bijvoorbeeld: ontwerp- en implementatieprocessen, beheeren beheersprocessen, leerprocessen, veranderprocessen en balanceerprocessen) met betrekking tot middelen: de onduidelijkheid voor de software-industrie welke samenwerkingsverbanden kunnen worden onderscheiden met betrekking tot continue verbetering. Onduidelijk is hoe taken en functies van betrokkenen zijn gedefinieerd.

Tweede conclusie, die samenhangt met de Wie-vraag, is dat onderscheid wordt gemaakt in verschillende groepen betrokkenen bij het bewerkstelligen van kwaliteit Globaal kan onderscheid worden gemaakt tussen makers en afnemers. Respectievelijk worden genoemd de ontwerpers alleen (Boehm en Cavano en McCall), gebruikers en makers (Willmer, Bemelmans, en Delen, Kouwenhoven en Rijsenbrij), het algemeen management en het projectmanagement (ISO 9000-3), en het hoger management en samenwerkingsverbanden tussen mensen (TQM). De belangrijkste beperking van al de benaderingen is de sterke nadruk op de makers van software-produkten (ontwerpers en projectmanagement). De derde conclusie is gerelateerd aan de Hoe-vraag ofwel de wijze waarop men tracht kwaliteit te bewerkstelligen. Respectievelijk kan onderscheid worden gemaakt tussen het vertalen van kwaliteitseisen naar kenmerken van een produkt (onder andere Willmer, en Delen, Kouwenhoven en Rijsenbrij), het vertalen van een kwaliteitsbelei(i naar richtlijnen en procedures (ISO 9000-3), en het streven naar integrale kwaliteitsverbetering, onder meer door speciale samenwerkingsverbanden te laten ontstaan die zich richten op continue verbetering van prodokten en processen (TQM). In de navolgende paragraaf gaan we nader in op de drie soorten objecten, produkten, processen en middelen, die in de verschillende kwaliteitsopvattingen aan de orde zijn gekomen. Doel is om door middel van een defini~ring van de verschillende typen objecten en hun eigenschappen het begrip kwaliteit 'handen en voeten' te geven. Concretisering van kwaliteit blijft dan niet beperkt tot een willekeurig deel- of aspectgebied, maar richt zich op integrale continue verbetering. ·

60

Hoofdstuk 4

4.3 Objecten van kwaliteit: produkten, processen en middelen 'Meten is weten'. Dat is binnen de kwaliteitswereld een veelvuldig geponeerde stelling. Uitgangspunt bij meten is dat duidelijk dient te zijn voor wie welk soort objecten van belang zijn en wat hun relevante eigenschappen zijn. Eerst daarna komt aan de orde het hanteren van normen, metingen en meetvoorschriften om concrete uitspraken te kunnen doen over kwaliteit. In de navolgende subparagrafen gaan we eerst kort in op de hoofdperspectieven van waaruit de drie objectklassen produkten, processen en middelen worden beschouwd. Vervolgens beschrijven we een aanzet tot het meetbaar maken van produkten, processen en middelen uit de literatuur. De belangrijkste beperkingen van die aanzet worden besproken.

4.3.1 Objecten van kwaliteit vanuit makers- en afnemersperspectief Makers en afnemers zijn bij het ontwikkelen van informatiesystemen of software vanuit versebillende perspectieven ge'interesseerd in (deels) dezelfde objecten. We illustreren dit aan de hand van de zoeklichtenmetafoor in figuur 4.5.

Figuur 4.5: Makers en afnemers: twee invalshoeken De strekking van deze metafoor is dat makers en afnemers alleen over die 'dingen' ofwel objecten en hun eigenschappen afspraken dienen te maken waarin zij een gemeenschappelijk belang hebben. Toegespitst op kwaliteit betekent dit dat makers bekend dienen te zijn met de objecten en hun eigenschappen die voor afnemers de kwaliteit bepalen. Afnemers dienen een beeld te hebben van de mogelijkheden en onmogenlijkheden die makers hebben om eigenschappen of kenmeiken aan objecten mee te geven. Doel is te voorkomen dat verwachtingen te hoog zijn gespannen enlof beloften niet (kunnen) worden nagekomen. We bespreken kort de verschillen in betekenis van produkt-, proces- en middelenobjecten vanuit respectievelijk het perspectief van makers en het perspectief van afnemers.

61

Kwaliteitsopvattingen: wat, wie en hoe Makers over produkten, processen en middelen De driedeling produkten, processen en middelen wordt door onder andere (Heemstra 1989) gehanteerd om voor software-ontwikkeling de belangrijkste karakteristieken te kunnen beschrijven. Tot de objectklasse van de produkten behoren zowel tussen-, deel- als eindprodukten van het ontwikkelwerk (bijvoorbeeld datamodellen, procestructuren, programmaontwerpschema's, code etcetera). Objecten uit de klasse van processen worden onderverdeeld aan de hand van de levenscyclus van een informatiesysteem (bijvoorbeeld analyse, ontwerp, en constructie). Tot de belangrijkste objecten in de klasse van middelen behoren de mensen die bij het werk zijn betrokken, hetzij als uitvoerders (bijvoorbeeld analisten, ontwerpers etcetera) hetzij als management (bijvoorbeeld projectleiders). Daarnaast worden methoden en geautomatiseerde gereedschappen genoemd.

Afnemers over produkten, processen en middelen Objecten die voor afnemers van belang zijn kunnen worden ontleend aan de literatuur over 'gebruikswaardering' van informatiesystemen, zie onder andere (Bailey en Pearson 1983). In een overzichtsartikel van deze literatuur geeft Kim (1990) een opsomming van de soorten objecten die voor gebruikers de kwaliteit bepalen. Kwaliteit wordt opgesplitst in de mate van waardering voor: de wijze van invoeren van gegevens in het systeem (objectklasse produkt) de wijze waarop gegevens worden uitgevoerd (objectklasse produkt) de wijze waarop gegevens worden verwerkt (objectklasse produkt) de geboden ondersteuning bij gebruik (objectklassen proces en middelen) de gebleken effectiviteit van informatie die door het systeem wordt verstrekt (objectklasse produkt) Samenvattend kan worden gesteld dat produkten, processen en middelen vanuit de verschillende perspectieven van makers en afnemers worden beschouwd. Voor wat betreft het produkt zijn afnemers geïnteresseerd in de werking daarvan binnen hun organisatie. Vaak wensen zij de informatie die wordt verstrekt door het systeem als 'het' produkt op te vatten. Eisen worden gesteld aan bijvoorbeeld de bruikbaarheid en de effectiviteit van informatie voor het kunnen nemen van beslissingen. Makers daarentegen beperken zich voor wat betreft het produkt veelal tot de deel- en tussenprodukten tijdens het ontwikkelwerk. Voor makers is een produkt vaak een software-applicatie waarbij als handreiking naar de gebruiker een handleiding is toegevoegd. Voor processen en middelen geldt iets soortgelijks. De kwaliteit van een informatiesysteem wordt voor afnemers mede bepaald door de geboden ondersteuning (bijvoorbeeld service) tijdens het werken met een systeem. Makers beperken zich veelal tot de ontwikkelprocessen tot aan oplevering van een informatiesysteem. Voor verschillen in de betekenis van middelen kunnen soortgelijke voorbeelden worden gegeven. Strekking van dit betoog is dat zowel verschillen als overeenkomsten in de betekenis van de objecten duidelijk moeten worden gemaakt voordat metingen kunnen worden verricht.

62

Hoofdstuk 4 Daarvoor is nodig dat objecten en hun eigenschappen worden geordend en duidelijk worden omschreven en gedefmieerd. In de volgende paragraaf bespreken we een aanzet voor een integrale ordening van objecten die een rol spelen bij het ontwikkelen van informatiesystemen (Bush en Fenton 1990).

4.3.2 Objecten van kwaliteit: ordening Het vakgebied van de softwaremetrieken is gericht op het concretiseren van kwaliteit (Bush en Fenton 1990, Meilor 1991, Pfleeger 1993). Enerzijds worden veel inspanningen verricht voor de ontwikkeling van individuele (geYsoleerde) metrieken, anderzijds wordt getracht ordening te brengen in de vele verschillende objecten en hun eigenschappen binnen het ontwikkelwerk. Door (Bush en Fenton 1990) is een aanzet gedaan om de drie klassen van software-objecten (produkten, processen en middelen) nader te beschrijven (zie figuur 4.6).

l

)~ prodiJeten

c:)

/\

software niet·software produl<:ten

produl<:ten

C) C) Figuur 4.6: Objecten van systeemontwikkeling (Bush en Fenton 1990) In hoofdzaak gaat het hier om objecten vanuit het perspectief van makers. Gesteld wordt dat elk onderdeel of elke component uit de levenscyclus van een informatiesysteem als een object in een van de drie klassen kan worden gedefmiëerd. Figuur 4.6 laat zien dat elk van de objectklassen produkten, processen en middelen verder wordt onderverdeeld in subklassen. We lichten deze figuur kort toe.

Processen worden omschreven als software-ontwikkeling gerelateerde activiteiten; processen hebben normaal gesproken een tijdsfactor. Dit betekent dat alles wat zich afspeelt binnen een bepaalde tijdsspanne als een proces kan worden beschouwd. Gesteld wordt dat alleen goed beschrijfbare activiteiten als automatiseerbare processen mogen worden beschouwd.

63

Kwaliteitsopvattingen: wat, wie en hoe Onderscheid wordt gemaakt tussen processen die niet direct verband houden met het ontwerpen (staffing related), bijvoorbeeld 'het afsluiten van contracten met klanten'; processen die direct te maken hebben met het ontwerp, bijvoorbeeld 'de specificatie van een datamodel', en processen die betrekking hebben op het inzetten en bedienen van geautomatiseerde middelen, bijvoorbeeld het gebruik van een codegenerator'.

Produkten zijn artefacten, opbrengsten, resultaten etcetera, die voortkomen uit softwareprocessen. Onderscheid wordt gemaakt in software producten (bijvoorbeeld: software zelf en bijbehorende ontwerpdocumentatie en handleidingen), en niet-software producten (bijvoorbeeld projectdocumentatie).

Middelen vormen een breed scala van 'items' of 'dingen' die de input van softwareprocessen vormen. Onderscheid wordt gemaakt tussen personele middelen (zowel individuen als teams), technische middelen (zowel hardware als software) en niet-technische middelen (zoals materialen en werkvoorzieningen). Voor de verschillende objectklassen en hun subklassen worden relevante eigenschappen van objecten beschreven. In de navolgende paragraaf gaan we daar nader op in.

4.3.3 Objecten van kwaliteit: interne en externe attributen Door (Bush en Fenton 1990) wordt onderscheid gemaakt tussen twee soorten eigenschappen waaraan metingen kunnen worden venicht. Deze worden aangeduid als interne en externe attributen. Gesteld wordt dat externe attributen eigenschappen of kenmerken zijn van objecten die alleen kunnen worden gemeten in relatie tot een omgev~ng. Dit houdt in dat voor meting van een extern attribuut ook altijd metingen aan andere (eltcterne) attributen moeten worden venicht. Interne attributen zijn attributen die 'zuiver' kunnen worden gemeten in termen van de produkten, processen en middelen zelf. Door (Fenton 1991) worden zowel voor produkten als voor processen en middelen externe en interne attributen onderscheiden. We bespreken voorbeelden van beide soorten attributen aan de hand van de onderstaande figuur 4.7. Vervolgens bespreken we enkele tekortkomingen en onduidelijkheden van met name het bepalen van proces- en middelenkwaliteit aan de hand van externe en interne attributen.

Produktattributen Externe attributen van een softwareprodukt kennen vele afhankelijkheidsrelaties met de omgeving waarin dat produkt wordt gebruikt. Bijvoorbeeld het externe attribuut betrouwbaarheid kan niet direct worden gemeten. De betrouwbaarheid van een softwareprodukt hangt af van onder meer de software of de programmacode maar ook van de hardware waarop die software of code is geïnstalleerd. Een ander voorbeeld is het externe attribuut gebruiksvriendelijkheid. Gebruiksvriendelijkheid hangt af van zowel de automatiseringskennis en -ervaring van een gebruiker die het systeem gebruikt als de vormgeving van de mensmachine-interface. 64

Hoofdstuk 4

OBJECTEN

ATIRIBUTEN

PRODUKTEN

INTERN

EXTERN

Specificaties

omvang,redundantie, functionaliteit, syntactische correctheid

begrijpelijkheid onderhoudbaarheid

Ontwerp

omvang, modulariteil, samenhang

complexiteit onderhoudbaarheid

Code

omvang, functionaliteit, complexiteit van het algoritme

betrouwbaarheid, bruikbaarheid, onderhoudbaarheid

PROCESSEN

INTERN

EXTERN

Ontwerp specificatie

tijd, inspanning, aantal veranderingen

kwaliteit, kosten, stabiliteit

Gedetailleerd ontwerp

tijd, inspanning, aantal gevonden specificatiefouten

kosten effeciMteil

Testen

tijd, inspanning, aantal gevonden fouten

kosten effectiviteit, stabilitei~ kosten

MIDDELEN

INTERN

EXTERN

Personeel

leeftijd, loonkosten

Teams Software

grootte, niveau van communicatie, gestructureerdheid, ... prijs, omvang, ...

produktiviteit, ervaring,intelligentie produktiviteit, kwaliteit

Hardware

prijs, snelheid, geheugencapaciteit

betrouwbaarheid, bruikbaarheid, ... betrouwbaarheid,

Kantoren

grootte, temperatuur, licht

comfort, kwaliteit

Figuur 4.7: Voorbeelden van software-ontwikkelobjecten en interne en externe kenmerken (Fenton 1991) Makers trachten te voldoen aan externe attributen door interne attributen te realiseren. Voor een afnemer van softwareprodokten of informatiesystemen zijn interne attributen vaak betekenisloos. Interne produktattributen komen overeen met de produktkenmerken zoals die in het eerste type kwaliteitsopvatting zijn besproken in dit hoofdstuk. Voorbeelden van interne attributen zijn respectievelijk complexiteit, modulariteit, syntactische correctheid etcetera.

65

Kwaliteitsopvattingen: wat, wie en hoe Procesattributen

In tegenstelling tot de externe produktattributen is er vooralsnog weinig eenduidigheid in de literatuur over externe attributen van een software-ontwikkelproces. Genoemd worden onder andere de kosteneffectiviteit en de stabiliteit van een ontwikkelproces. Ook deze externe attributen kennen weer tal van afhankelijkheden. Bijvoorbeeld het externe attribuut stabiliteit (van bijvoorbeeld het proces van specificeren) hang af van het aantal keren dat een specificatie wordt verandert, de periode die in beschouwing wordt genomen en de kennis en ervaring van de personen die dat proces uitvoeren. Tot nu toe is slechts een beperkt aantal interne attributen van processen beschreven. Deze zijn respectievelijk: de tijdsduur van een proces, de inspanning die met het proces gemoeid is, en het aantal gebeurtenissen van een bepaald type dat gedurende een proces optreedt. Voorbeelden van interne procesattributen zijn respectievelijk de tijd die, wordt besteed aan het testen van een softwareprodukt en het aantal fouten dat in die tijd wordt gevonden. Meting hiervan geeft, naast inzicht in de betrouwbaarheid van een systeem (produktk:waliteit), inzicht in de kosteneffectiviteit van het testen. Middelenattributen

De diversiteit van de middelen die kunnen worden toegepast in het ontwikkelwerk is groot. Als gevolg daarvan bestaat er een grote verscheidenheid aan externe middelenattributen. Als voorbeelden kunnen worden genoemd de produktiviteit van personeel, de produktiviteit van samenwerkingsverbanden ('teams'), de bruikbaarheid van methoden en gereedschappen etcetera. Ook hier geldt dat deze externe attributen alleen indirect te meten zijn. Bijvoorbeeld de produktiviteit van personeel kan afhangen van de leeftijd, de kennis en de ervaring; de produktiviteit van teams hang af van zowel de personen binnen het team als van de wijze waarop het team is georganiseerd (qua verantwoordelijkheden, samenwerkingsvormen etcetera), de bruikbaarheid van methoden en gereedschappen is onder meer afhankelijk van de kosten die worden besteed aan invoering en inleren. In het voorgaande is reeds een aantal voorbeelden van interne middelenattributen genoemd,

c.q. de ervaringsjaren van personeel, de kosten van opleidingen voor het leren werken met nieuwe methoden en gereedschappen, de omvang en de structuur van teams. Samenvatting Met betrekking tot het bepalen van produktkwaliteit wordt aangesloten bij de huidige opvattingen over produktkwaliteit De externe en interne attributen die worden onderscheiden komen in grote lijnen overeen met de kwaliteitsfactoren en -attributen of -criteria uit de eerder in dit boek genoemde kwaliteitsopvattingen, bijvoorbeeld van Willmer (1985) of van Cavano en McCall (1978). Bush en Fenton gaan echter een stap verder dan genoemde auteurs door ook een poging te doen proces- en middelenkwaliteit te 'concretiseren. De vraag is echter of proces- en middelenkwaliteit kunnen worden bepaald door metingen te verrichten aan de in de figuur 4.7 genoemde externe en interne attributen. We illustreren I

66

Hoofdstuk 4 deze onduidelijkheid met een voorbeeld. Als extern procesattribuut wordt genoemd de kosten van een proces. Als voorbeeld van een extern middelenattribuut wordt genoemd de produktiviteit (van medewerkers). Tot de interne attributen van processen behoren onder meer de attributen tijd en de inspanning die een proces vergen. Als interne attributen van middelen worden genoemd de leeftijd en de ervaringsjaren van personeel en de kosten van methoden en gereedschappen. De vraag is of produktiviteitsmetingen en metingen aan tijd en geld inzicht kunnen geven in de kwaliteit van ontwikkelprocessen of -middelen. Of wordt proces- en middelenkwaliteit bepaald door andere attributen zoals bijvoorbeeld het in figuur 4.7 genoemde procesattribuut stabiliteit In dit verband roept ook het externe attribuut 'kwaliteit' in figuur 4.7 van zowel processen als middelen vragen op. Kortom, naast een verdere concretisering van produktkwaliteit blijven er vooralsnog vragen onbeantwoord op het gebied van proces- en middelenkwaliteit In hoofdstuk 6 wordt hier nader op ingegaan.

4.4 SamenvaWng en conclusies Er zijn drie kwaliteits'stromingen' binnen de software-industrie. Tegen de achtergrond van het ontwikkelaspectenmodel uit hoofdstuk 3 blijkt dat de beschreven kwaliteits'stromingen' elkaar aanvullen en met elkaar samenhangen. Eningszins 'zwart-wit' geformuleerd staat in de produktkwaliteitsstroming (onder andere Boehm) het ontwikkelaspect modelleren centraal. In de proceskwaliteitsstroming (ISO 9000) staat het ontwikkelaspect beheersen centraal. In de integrale kwaliteitsstroming van TQM gaat de aandacht naast inhoudelijke aspecten en beheersaspecten ook uit naar middelenaspecten, met name mensen. Centraal staat in die stroming het evolueren en verbeteren, ofwel de ontwikkelaspecten leren en veranderen. Uit de beschrijving van specifieke kwaliteitsopvattingen vanuit de invalshoeken Wat, Wie en Hoe werden drie hoofdconclusies getrokken, die we als volgt samenvatten: met betrekking tot het Wat: maak onderscheid tussen drie objectklassen binnen het ontwikkelwerk, te weten produkten, processen en middelen met betrekking tot het Wie: maak onderscheid tussen twee hoofdgroepen van betrokkenen: makers en afnemers met betrekking tot het Hoe: maak onderscheid tussen de wijze waarop -men kwaliteit tracht te bewerkstelligen. Respectievelijk: kwaliteits- en produktkenmerken defmiëren, procedures en normen nastreven, periodiek verbeteringsvoorstellen binnen het ontwikkelwerk genereren door middel van groepswerk.

In literatuur en praktijk worden pogingen gedaan om de verschillende objecten binnen het ontwikkelwerk te ordenen, te definitsren en te concretiseren. Duidelijk is dat het onderscheid tussen produkten, processen en middelen en het benoemen van eigenschappen

67

Kwaliteitsopvattingen: wat, wie en hoe

daarvan (externe en interne attributen) een vollediger beeld geeft van het omgaan met kwaliteit dan wanneer men zich beperkt tot alleen produk.tkwaliteit. In dit hoofdstuk zijn ook enkele beperldngen gesignaleerd. Op de eerste plaats kan worden gesteld dat men zich met name richt op objecten vanuit het perspectief van makers. Op de tweede plaats zijn voor wat betreft proces- en middelenkwaliteit vooralsnog een aantal vragen onbeantwoord gebleven. Met name geldt dit voor de eigenschappen (externe en interne attributen) die worden gedefinieerd voor processen en middelen.

In de volgende hoofdstukken van dit boek wordt getracht verbetering aan te brengen in het omgaan met produkt-, proces- en middelenkwaliteit In hoofdstuk 5 richten we ons eerst op produktkwaliteit In tegenstelling tot veel kwaliteitsopvattingen in literatuur en praktijk leggen we daarbij het accent op het 'ajnemersperspectief'. In hoofdstuk 6 wordt nader ingegaan op het omgaan met proces- en middelenkwaliteit Om, naast het ordenende werk in dit boek, ook een operationele bijdrage te leveren aan het omgaan met kwaliteit en kwaliteitsbeheersing wordt in de navolgende hoofdstukken een methode ontwikkeld voor het specificeren van kwaliteitseisen.

68

5

PRODUKTKWALITEIT

5.1 Inleiding Informatiesystemen en softwareprodukten vari~ren van relatief eenvoudige tot uiterst complexe en omvangrijke systemen. Deze systemen worden toegepast in sterk verschillende bedrijfssituaties met uiteenlopende doelstellingen. Informatiesystemen en software-applicaties kunnen totaaloplossingen zijn, maar bieden meestal slechts deeloplossingen binnen een bepaalde bedrijfsproblematiek. Op grond van de grote diversiteit is het niet eenvoudig om generieke uitspraken te doen over de vereiste of gewenste kwaliteit van informatiesystemen. Afhankelijk van de situatie is de 'stem' van een afnemer in het ene geval bepalend en uiterst noodzakelijk, terwijl in het andere geval de rol van een afnemer zeer beperkt blijft. Voor makers geldt iets soortgelijks. In sommige situaties is het realiseren van kwaliteit een kwestie van het hanteren van routinestandaards, terwijl in andere situaties het uiterste wordt gevergd van hun ontwerpcreativiteit Het bewerkstelligen van produktkwaliteit is een complexe zaak. In literatuur en praktijk zijn de afgelopen jaren verschillende pogingen gedaan om het produktkwaliteitsbegrip verder uit te werken. Met name voor wat betreft defini~ring en concretisering van produktkwaliteit zijn vorderingen geboekt. Echter, dit hoofdstuk zal laten zien dat er op een belangrijk punt tekortkomingen zijn blijven bestaan. Met name zal blijken dat in de software-industrie niet kan worden gesproken van een 'user based' benadering van produktkwaliteit. Mnemers hebben vooralsnog te weinig houvast om hun wensen, behoeften en verwachtingen uit te drukken in voor hun relevante en adequate kwaliteitseisen. Dit hoofdstuk tracht daar verbetering in te brengen. Er wordt een uitwerking van het begrip produktkwaliteit gegeven die afnemers en makers ondersteunt bij de identificatie van produktkwaliteitseisen. De structuur van dit hoofdstuk is als volgt. In paragraaf 5.2 wordt eerst kort ingegaan op het begrip produktkwaliteit volgens de literatuur. De beperkingen daarvan worden besproken in paragraaf 5.3. In paragraaf 5.4 wordt vervolgens een verbeteringsvoorstel ontwikkeld. De toepasbaarheid daarvan wordt gedemonstreerd in paragraaf 5.5. Paragraaf 5.6 sluit dit hoofdstuk af met een samenvatting en conclusies.

5.2 Wat wordt verstaan onder produktkwaliteit in de literatuur? In deze paragraaf bespreken we drie soorten uitwerkingen van het begrip produktkwaliteit uit de literatuur. Het betreft respectievelijk de definities van produktkwaliteit volgens ISO (1986), en twee pogingen om het begrip produktkwaliteit modelmatig van een grondslag te voorzien. De kwaliteitsmodellen worden respectievelijk het 'kwaliteitsprofiel' (Kaposi en Kitchenham 1987), en de 'conceptstructuur' genoemd (Serc-Quint 1992). We lichten elk van deze uitwerkingen van het begrip produktkwaliteit kort toe. In paragraaf 5.3 geven we een samenvatting en worden de beperkingen besproken.

69

Produktkwaliteit

5.2.1 Definities van standaardisatie

produktkwaliteit

volgens

organisaties

voor

Door verschillende organisaties die zich bezig houden met standaardisatie en normalisatie van kwaliteit zijn defmities opgesteld van produktkwaliteit en aanverwante zaken zoals kwaliteitsnormen, -metrieken, -meetvoorschriften etcetera. Genoemd kunnen worden de Europese Organisatie voor Qualiteitscontrole (EOQC), de Intemationele Organisatie voor Standaardisatie (ISO), de IEEE Qualiteitsmetrieken en Standaards Commissie en de Internationale Organisatie voor Standaardisatie (ISO). Produktkwaliteit wordt door de ISO als volgt gedefmieerd: het geheel van eigenschappen van een produkt of dienst waardoor een produkt voldoet aan gespecificeerde of impliciete behoeften van afnemers (ISO 8402: 1986) Door IEEE (1986) wordt het begrip produkteigenschap uitgewerkt aan de hand van drie basisconcepten en hun relaties. Deze basisconcepten zijn respectievelijk: het concept kwaliteitsfactor, het concept kwaliteitscriterium en het concept kwaliteitsmetriek. Eigenschappen van een softwareprodukt worden uitgedrukt in kwaliteitsfactoren. Voorbeelden van kwaliteitsfactoren zijn betrouwbaarheid, onderhoudbaarheid en gebruiksvriendelijkheid van software. Zoals eerder besproken in hoofdstuk 4 zijn deze factoren vaak sterk geaggregeerd; zo wordt bijvoorbeeld een factor zoals betrouwbaarheid verder opgesplitst in subfactoren zoals juistheid, volledigheid, nauwkeurigheid en toegankelijkheid. Kwaliteitscriteria zijn produktkenmerken die in een softwareprodukt worden ingebouwd. Voorbeelden zijn de criteria modulariteit, consistentie, gestructureerdheid etcetera. Met behulp van kwaliteitsmetrieken kan de mate bepaald worden waarin software aan een bepaald kwaliteitscriterium voldoet. Over het algemeen zijn meerdere metrieken voorhanden voor de bepaling of een softwareprodukt al dan niet voldoet aan bepaalde kwaliteitscriteria. De onderlinge relaties tussen kwaliteitsfactoren en -criteria en tussen kwaliteitscriteria en -metrieken zijn van het type veel-op-veel (n:m). In vrijwel alle literatuur over softwarekwaliteit wordt gerefereerd aan genoemde kwaliteitsbegrippen. Dit geldt ook voor de twee uitwerkingen van het kwaliteitsbegrip die uit literatuuronderzoek zijn geselecteerd en die in de navolgende paragraaf worden beschreven.

5.2.2 Het kwaliteitsprotiel volgens (Kaposi en Kitchenham 1987) Door Kaposi en Kitchenham wordt een model voor produktkwaliteit geïntroduceerd dat het kwaliteitsprofiel wordt genoemd. Doel van dit model is de verschillende soorten eisen, wensen en verwachtingen van afnemers te rubriceren en vast te leggen. Het kwaliteitsprofiel beperkt zich niet tot alleen kwantificeerbare eisen; ook kwalitatieve behoeften, wensen en verwachtingen dienen geïdentificeerd en vastgelegd te worden, zie figuur 5.1.

70

Hoofdstuk 5

/"""'"rsprofle~ transcendente

kwallteits-

elgensc,.."".n

/'"'I"'"

kwaliteitsmetrieken

kwaliteitsattributen

waarderings-

lndror·n kwaliteits ·ratings·

Figuur 5.1: Het kwaliteitsprotiel volgens (Kaposi en Kitchenham 1987) Een kwaliteitsproftel is een aggregaat van drie klassen van eigenschappen: de klasse van transcendente eigenschappen, de klasse van kwaliteitsfactoren en de klasse van vvaarderingsindicaoren. Overeenkomstig de opvatting van (Garvin 1988) kunnen transcendente eigenschappen niet vvorden gedefinieerd of geanalyseerd. Gesteld vvordt echter dat ontvvikkelaars van informatiesystemen open dienen te staan voor dit soort eigenschappen die, hoevvel nieteenduidig specificeerbaar, vaak vvel als vanzelfsprekend vvorden beschouvvd door afnemers of klanten. Uiteraard kan men zich afvragen op vvelke vvijze makers dit soort vanzelfsprekende eisen moeten identificeren en hoe dit soort eisen moet vvorden gerealiseerd. Het kwaliteitsprotiel geeft daarop geen antvvoord, er vvordt geen verdere uitvverking gegeven aan de transcendente eigenschappen. De begrippen kwaliteitsfactor, -metriek en kwaliteitsattribuut vvijken enigszins af van de in

voorgaande subparagraaf beschreven kwaliteitsbegrippen. Kvvaliteitsfactoren vvorden beschouvvd als functies met als basisparameters metrieken en attributen. Attributen zijn niet kvvantificeerbaar. Zij geven de aan- of afvvezigheid van een kenmerk door middel van een Boolean variable. Bijvoorbeeld kan ermee vvorden vveergegeven of vvel of niet gebruik is gemaakt van standaards (bijvoorbeeld voor het ontvverp van de lay-out van de mensmachine-intetface). Metrieken daarentegen kwantificeren de mate vvaarin een bepaalde eigenschap aanvvezig is in het systeem. Bijvoorbeeld kunnen uitspraken vvorden gedaan over de betrouvvbaarheid van een softvvareprodukt door de vvaarschijnlijkheid te bepalen dat er geen fouten of storingen optreden door het gebruik van de softvvare. De vvaarschijnlijkheid is zovvel een functie van de invoer en het gebruik van een systeem als van het bestaan van fouten in de softvvare (IEEE 1983). De invoer van het systeem bepaalt of bestaande fouten aan het licht komen. Opgemerkt moet vvorden dat vvanneer voor de bepaling van de kvvaliteit van een softvvareprodukt door tvvee verschillende personen dezelfde 'objectieve' metrieken en attributen vvorden gehanteerd voor een kwaliteitsfactor, toch geheel verschillende 71

Produktkwaliteit interpretaties kunnen ontstaan. Bijvoorbeeld afhankelijk van de voorkeuren van de afnemer en het beoogde gebruik van het softwareprodukt kan het gebruik van verschillende kleuren op een beeldscherm als hinderlijk (lage kwaliteit) of aantrekkelijk (hoge kwaliteit) worden beschouwd.

Waarderingsindicatoren zijn functies met als basisparameters kwalitatief bepaalde waarderingen die 'ratings' worden genoemd. 'Ratings' zijn bestemd om waarde-oordelen vast te leggen, c.q. de mate waarin groepen of individuen een systeem een bepaalde eigenschap toekennen. Bijvoorbeeld kunnen afnemers of groepen afnemers worden gevraagd om hun subjectieve ervaring met betrekking tot de gebruiksvriendelijkheid van een systeem uit te drukken op een schaal van nul tot en met tien. Nul heeft de betekenis van een extreem slechte gebruiksvriendelijkheid en tien betekent een extreem goede gebruiksVriendelijkheid. Tot zover een uitwerking van produktkwaliteit volgens Kaposi en Kitchenham (1987). In de navolgende paragraaf beschrijven we een tweede uitwerking van het begrip produktkwaliteit die recent in de literatuur is verschenen. Vervolgens geven we een samenvatting in paragraaf 5.3 en bespreken we kort enkele beperkingen.

5.2.3 Een conceptstructuur van produktkwaliteit volgens · (Serc-Quint (1992)) In Serc-Quint (1992) zijn de concepten die een rol spelen bij produktkwaliteit weergegeven in een model dat de conceptstructuur voor produktkwaliteit wordt genoemd, zie figuur 5.2. We merken op dat in vergelijking met wat anderen eerder hebben gedaan (bijvoorbeeld Boehm, Cavano en McCall) geen nieuwe concepten worden aangereikt maar dat gepoogd wordt de concepten met hun onderlinge samenhang nauwkeurig te beschrijven. De figuur dient als volgt te worden 'gelezen •. Eigenschappen (lees: kwaliteitsfactoren) worden gerealiseerd door het nemen van maatregelen. Aan de hand van indicatoren (lees: metrieken) dient te worden bepaald of een softwareprodukt na het nemen van maatregelen de gewenste eigenschappen bezit. Tussen produkteigenschappen en indicatoren bestaan n:m-relaties. Een produkteigenschap kan dus aan de hand van verschillende indicatoren worden aangetoond. Ook kan een bepaalde indicator een aanwijzing geven voor verschillende kwaüteitseigenschappen van een softwareprodukt Meetvoorschriften zijn voorschriften en richtlijnen voor het verrichten van metingen c.q. het bepalen van een indicator. Als belangrijke kenmerken van meetvoorschriften worden onder meer genoemd de inspanning die voor een meting dient te worden verricht. In Sero-Quint (1992) wordt met name aandacht besteed aan het begrip indicator. Hoofddoel van de conceptstructuur is namelijk het concretiseren en meetb~ar maken van produktkwaliteit Onder andere worden indicatoreisen en verschillende mimieren om de waarden van indicatoren (soorten metingen en meetschalen) te bepalen beschreven. Met betrekking tot indicatoreisen wordt gerefereerd aan (Watts 1987, Humphrey 1989) en worden met name genoemd de eis van objectiviteit en de eis van validiteit.

72

Hoofdstuk 5

Figuur 5.2: De conceptstructuur van produktkwaliteit volgens (Sero-Quint 1992) De eis van objectiviteit heeft betrekking op het feit of de indicator bij herhaalde meting (door verschillende personen) dezelfde waarde geeft. De eis van validiteit heeft betrekking op het feit dat een indicator inderdaad een maat is voor een bedoelde eigenschap. Bij het bepalen (c.q. meten) van eigenschappen kan de waarde van indicatoren op verschillende wijzen worden vastgesteld. Onderscheid wordt gemaakt tussen enerzijds persoonsbepaalde en instrumentbepaalde waarden van indicatoren en anderzijds de verschillende meetschalen die kunnen worden gehanteerd. Bij persoonsbepaalde indicatoren speelt persoonlijke inschatting (subjectieve oordeelsvorming) een rol. Het tijdsaspect (momentopnames) is in dit geval belangrijk omdat bij bemaling een andere waarde kan worden toegekend aan dezelfde indicator. Een instrumentbepaalde waarde van een indicator is onafhankelijk van menselijke waardebepaling. De waarde wordt geheel door het meetinstrument bepaald. Indicatoren kunnen worden gemeten op verschillende soorten meetschalen, te weten de nominale, de ordinale, de interval- en de ratio-schaal. Een voorbeeld van een nominale meetschaal is de schaal van programmeertalen met als waarden bijvoorbeeld 'Pascal', 'Cobol' etcetera. Aangegeven kan worden of softwareprodukten qua waarde van de indicator 'programmeertaal' tot eenzelfde klasse behoren of niet. Een voorbeeld van een ordinale meetschaal is een meetschaal voor de complexiteit van een softwareprodukt met de categorieën 'laag', 'gemiddeld' en 'hoog'. Naast classificatie is ook rangschikking van softwareprodukten mogelijk op deze schaal. Op een interval-schaal is het mogelijk om naast classificatie en rangschikking ook de afstand tussen twee waarden te bepalen. De waarden van indicatoren op een intervalmeetschaal hebben een vaste afstand ten opzichte van elkaar. Van twee waarden kan worden gezegd dat de ene waarde n groter is dan de andere. Niet gezegd kan worden dat de ene waarde n keer zo groot is dan de andere. De ratioschaal tot slot, heeft een natuurlijk nulpunt. Naast classificatie, rangschikking en afstand tussen twee waarden is ook het bepalen van verhoudingen mogelijk. Bijvoorbeeld kan de waarde van een indicator op deze schaal met een percentage worden weergegeven

73

Produktkwaliteit (bijvoorbeeld de beschikbaarheid van softwareprodukt is 99 %). Ook kunnen uitspraken worden gedaan dat de ene waarde n keer zo groot is als de andere (bijvoorbeeld voor de responsesnelheid van twee verschillende softareprodukten).

5.3 Beperkingen in het produktkwaliteitsbegrip In deze paragraaf vatten we eerst kort samen wat de belangrijkste resultaten zijn van de inspanningen in de literatuur om het begrip produktkwaliteit verder uit te' werken en van een grondslag te voorzien. Vervolgens bespreken we de belangrijkste beperkingen en bepalen we een oplossingsrichting.

Samenvatting Organisaties voor standaardisatie trachten eenduidige definities te bieden voor produktkwaliteitsbegrippen. De standaards die daarmee worden gesteld dienen ter voorkoming van begripsverwarring en dienen als uitgangspunt voor afstemming tussen makers en afnemers. Het kwaliteitsprofiel van Kaposi en Kitchenham is met name bedoeld om de verschillende soorten behoeften, wensen en verwachtingen van afnemers zo goed mogelijk te kunnen identificeren en vastleggen. Drie soorten eigenschappen van softwareprodukten worden onderscheiden: transcendente eigenschappen, kwaliteitsfactoren en waarderingsindicaties. De conceptstructuur volgens Serc-Quint heeft hoofdzakelijk als doel de . achterliggende concepten voor het bepalen van produktkwaliteit in hun onderlinge samenhang te beschrijven. In die zin is het hoofdzakelijk een samenvatting van eerder gedaan werk. Centraal staat het concretiseren van produktkwaliteit voor makers. Overigens merken we hier op dat in (Serc-Quint) op basis van de conceptstructuur ook wordt gepoogd een bijdrage te leveren aan het omgaan met de vele onderlinge relaties tussen kwaliteitseigenschappen. We komen daar op terug in hoofdstuk 7.

Beperkingen De drie besproken uitwerkingen van het begrip produktkwaliteit hebben gemeenschappelijk dat uitgegaan wordt van gespecificeerde kwaliteitseisen (-factoren of -eigenschappen) van afnemers. Vervolgens dienen deze ingebouwd te worden in een softwareprodukt Beschreven wordt op welke wijze kan worden gecontroleerd (lees: gemeten) ~of een produkt daadwerkelijk aan de eisen voldoet. We constateren een aantal beperkingen voor zowel makers als afnemers. Omdat in literatuur en praktijk tot nu toe met name het accent ligt op de wijze waarop produktkwaliteit moet worden gerealiseerd (door makers) richten we ons na een korte bespreking van de beperkingen voor makers op de beperkingen voor afnemers.

74

Hoofdstuk 5 Voor makers hebben de beperkingen betrekking op het realiseren van produktkwaliteit. Naast de beperkte inzichten in de wijze waarop en de mate waarin kwaliteitseisen elkaar bernvloeden geldt als een van de grootste beperkingen de (beperkte) validiteit van kwaliteitsmetrieken. Bijvoorbeeld: meet een metriek voor de complexiteit 'echt' wat complexiteit is ? Of wordt bijvoorbeeld slechts de complexiteit van individuele programmacomponenten gemeten in plaats van de complexiteit van het gehele softwareprodukt. Vooralsnog wordt het realiseren van softwarekwaliteit en het omgaan met metrieken gekenmerkt door een hoge mate van subjectiviteit (van de makers) (van Vliet

1993). Voor afnemers kunnen de volgende beperldngen voor het omgaan met produktkwaliteit worden genoemd. Op de eerste plaats kan worden gesteld dat de literatuur óf onduidelijk blijft over wat met een produkt wordt bedoeld óf een uiterst beperkte produktdefinitie hanteert. Meestal lijkt met een softwareprodukt code en de daarbij behorende documentatie te worden bedoeld (waarbij overigens onduidelijk blijft welk soort documentatie wordt bedoeld). Een produkt voor afnemers heeft minstens zo vaak: betrekking op een informatiesysteem ingebed en werkend in een bedrijfssituatie als op een op zichzelf staand softwareprodukt. Op de tweede plaats kan worden genoemd de beperking dat zonder meer wordt aangenomen dat afnemers van informatiesystemen of softwareprodukten hun wensen en behoeften kunnen vertalen in (vaak: op technische wijze) gespecificeerde kwaliteitseisen of produkteigenschappen. In geen van de kwaliteitsopvattingen in de literatuur wordt nader ingegaan op de manier waarop eisen op grond van verwachtingen en behoeften van afnemers kunnen worden gespecificeerd. In de meeste publicaties zijn gespecificeerde eisen of eigenschappen van een softwareprodukt het uitgangspunt voor het bewerkstelligen van kwaliteit.

5.4 Een verbeteringsvoorstel: produktdimensies als uitgangspunt Om op gestructureerde wijze verschillen in betekenis en definities van softwareprodukten te kunnen beschrijven, en in relatie daarmee kwaliteit, hanteren we in deze paragraaf verschillende dimensies van een produkt. Deze dimensies houden verband met de ontwikkelaspecten modelleren, beheersen, en leren en veranderen. Balanceren, dat als ontwikkelaspect niet op zichzelf staat maar steeds in relatie moet worden gezien met een of meer van de andere ontwikkelaspecten (zie hoofdstuk 3), blijft bij de produkttypering in dit boek buiten beschouwing. Gebaseerd op de twee in literatuur en praktijk meest bekende en uitgewerkte ontwikkelaspecten modelleren en beheersen onderscheiden we twee produktdimensies. Respectievelijk zijn dit de dimensie van: de 'ontwerp'-scope van een produkt (of: wat wordt gemodelleerd en wat betekent kwaliteit daarvan ?) de 'beheers' -toestanden van een produkt (of: welke toestanden doorloopt een produkt en hoe varieert kwaliteit daarmee ?)

75

Produktkwaliteit Zoals reeds eerder venneld in hoofdstuk 3 gaat het hier respectievelijk om een inhoudelijke dimensie en om een tijdsdimensie van een produkt De inspanningen in de softwarewereld hebben zich jarenlang toegespitst op deze twee produktdimensies. Recent ontstaat in de softwarewereld in toenemende mate belangstelling voor het opnieuw gebtuiken van eerder gedaan werlc. Langzaam maar zeker raakt men ervan overtuigd dat verbeteringen alleen tot stand kunnen komen wanneer wordt geleerd van de eigen resultaten (é~ fouten). Alleen dan kunnen blijvende veranderingen (lees: verbeteringen) worden doorgevoerd. Zo beschouwd vonnen de ontwikkelaspecten leren en veranderen een basis voor het hergebruiken van eerder gedaan werk. Uiteraard wisselen de mogelijkheden om te leren en te veranderen van situatie tot situatie. Bij de ontwikkeling van geheel nieuwe (unieke) prodakten kan over het algemeen slechts in beperkte mate gebruik worden gemaakt van eerder gedaan werk. Bij de ontwikkeling van nieuwe versies van s$daardprodukten daarentegen speelt hergebruik een belangrijke rol. Op basis van het toenemend belang van hergebruik van software, onderscheiden we in dit boek naast de twee eerder genoemde produktdimensies nog een derde produktdimensie, te weten de dimensie van: de uniekheid van een produkt (of: in welke mate is het produkt dat wordt ontwikkeld een nieuw produkt, hoe kan worden geleerd van eerder gedaan werk, en hoe varieert de kwaliteit van een produkt daannee ?) We merken op dat de drie dimensies scope, toestanden en uniekheid van een produkt hier als orthogonaal worden beschouwd. Door de dimensies tezamen wordt een drie dimensionale ruimte opgespannen waarin elk punt een bepaald infonnatiesysteem of softwareprodukt representeert. In deze paragraaf beperlcen we ons tot prodakten (c.q. produktomschrijvingen) op elk van de drie dimensies. Allereerst dient namelijk het bestaansrecht van elke dimensie nader te worden toegelicht. Binnen elke dimensie worden twee uiterste vonnen van een produkt beschreven en vervolgens wordt het gradueel verloop van een produktomschrijving binnen een dimensie beschreven. Aangegeven wordt hoe produktkwaliteit daannee samenhangt.

5.4.1 De scope van een produkt Uit de bespreking van de kwaliteitsopvattingen in hoofdstuk 4 is duidelijk geworden dat infonnatiesystemen en softwareprodutten verschillend kunnen worden afgebakend en gedefinieerd. Mwisselend treffen we aan: de software ofwel de souree-code als produkt (Boehm et al 1978), het infonnatiesysteem inclusief procedures als produkt (Cavano en McCall 1978), en het infonnatiesysteem en de te verstrekken infonnatie als produkt (Delen en Rijsenbrij 1990a, 1990b). De vraag is op welke wijze produktkwaliteit daannee varieert We beschrijven in deze paragraaf twee verschillende reikwijdtes van een produkt. Op de eerste plaats een scope die beperkt is tot een systeem dat 'op zichzelf staat', ten tweede een scope die uitgebreid is tot en met de omgeving van een produkt. De consequenties voor produktkwaliteit door het hanteren van een verschillende produktscope worden met enkele voorbeelden toegelicht.

76

Hoofdstuk 5 Een produkt als op zichzelf staand systeem In de kwaliteitsopvatting van (Boehm et al 1978) heeft kwaliteit betrekking op de kwaliteit van software. Boehm geeft expliciet aan dat daarmee de souree-code wordt bedoeld. Door (Willmer 1985, Cavano en McCall 1978) wordt ook documentatie tot het produkt gerekend (zowel handleidingen voor de gebruiker als voor de beheerder). Specifieke kwaliteitskenmerken daarvan worden echter niet gegegeven. Genoemde auteurs houden kwaliteitskenmerken van hardware buiten hun kwaliteitsopvatting. In genoemde opvattingen wordt getracht de scope van een produkt en de kwaliteit daarvan beperkt te houden tot een 'softwareprodukt op zich'. Dit heeft consequenties voor de betekenis van produktkwaliteit en de relevantie van kwaliteitseisen.

Hoofddoelstelling voor makers is een softwareprodukt op te leveren dat correct functioneert. Dat bepaalt in dit geval de kwaliteit van een produkt. Correct functioneren betekent hier functioneren overeenkomstig de specificaties. Verder trachten makers kwaliteit te realiseren door de softwareprogrammatuur gestructureerd te ontwerpen, de efficitSntie van de programmatuur te vergroten, het computergeheugengebruik (bijvoorbeeld de bezettingsgraad) te verbeteren, de toegankelijkheid van gegevensbestanden te verbeteren etcetera. Al deze activiteiten zijn sterk gericht op de interne structuur en werking van een softwareprodukt. De relaties met de omgeving en de afstemming van een systeem daarop (zowel op de kenmerken van een bedrijfssituatie als op de kenmerken van gebruikers) worden van ondergeschikt belang beschouwd.

Een produkt ingepast in een omgeving In de kwaliteitsopvatting van (Bemelmans 1991, Delen en Rijsenbrij 1990a, 1990b) is de definitie van een produkt niet beperkt tot software met bijbehorende documentatie. Deze auteurs onderscheiden twee verschillende defmities van een produkt; respectievelijk het produkt informatiesysteem en het produkt informatie. De scope van het produkt wordt daarmee uitgebreid tot en met de (directe) omgeving van dat produkt. Het produkt informatiesysteem dient te worden opgevat als het geautomatiseerde én niet-geautomatiseerde deel waaronder de procedures voor de aansluiting op de taken van afnemers. Het produkt informatie dient te worden opgevat als een produkt dat een directe bijdrage moet leveren aan het verwezenlijken van de doelstellingen van een organisatie.

De kwaliteit van een informatiesysteem, ingepast in een omgeving, wordt door meer zaken bepaald dan de kwaliteit van alleen de software (eventueel met hardware en documentatie). Naast het informatiesysteem zelf speelt de omgeving een rol bij de bepaling van de vereiste produktkwaliteit. Bijvoorbeeld geldt dit voor de aansluiting van een informatiesysteem op de handmatige procedures binnen een bedrijfsfunctie of taakgebied. Ook de gewenste mate van afdekking (lees: ondersteuning) van taken binnen de bedrijfsfunctie en de beschikbaarheid (naar tijd en/of plaats) van een systeem kunnen bepalend zijn voor de produktkwaliteit. Duidelijk is dat voor het specificeren van kwaliteitseisen specifieke kennis van het taakgebied en van de afnemers daarbinnen noodzakelijk is. Nog belangrijker worden kennis en inzicht in een bedrijfssituatie wanneer afnemers expliciet

77

Produktkwaliteit kwaliteitseisen aan infonnatie specificeren. Deze kwaliteitseisen hebben bijvoorbeeld betrekking op de effectiviteit van infonnatie voor de besluitvonning. Samenvatting De omschrijvingen van een produkt binnen de dimensie scope verlopen gradueel. We onderscheiden de volgende produktomschrijvingen waarbij we telkens beschrijvingen geven van produktkwaliteit het produkt software: produktkwaliteit betekent voldoen aan specificaties het produkt software plus hardware: produktkwaliteit is onder andere gebaseerd op een efficient gebruik van technische middelen het produkt software plus documentatie: produktkwaliteit heeft ónder andere te maken met de toegankelijkheid en hanteerbaarheid van de documentatie het produkt infonnatiesysteem: produktkwaliteit is gebaseerd op onder andere de aansluiting van een systeem op handmatige procedures en de geboden afdekking van taken het produkt infonnatie: produktkwaliteit wordt uitgedrukt in de waarde van de infonnatie voor de besluitvonning Uiteraard zijn verlijDingen in bovengenoemde opdeling mogelijk. Het doel is echter om duidelijk te maken dat afhankelijk van de scope van een produkt produktkwaliteit op verschillende manieren wordt uitgedrukt.

5.4.2 De toestanden van een produkt Oplevering van een produkt. bijvoorbeeld overdracht aan de klant of afnemer, betekent niet per definitie het einde van het ontwikkelwerk. Door (Looijen 1993) worden verschillende toestanden beschreven waarin een infonnatiesysteem zich ná oplevering kan bevinden. Respectievelijk wordt onderscheid gemaakt tussen de ontwerptoestanden (vóór oplevering van een produkt), de toestanden van invoering in een organisatie (tijdens en direct ná oplevering), de toestanden van exploitatie en beheer (onder andere service) en de toestanden van wijziging. Met betrekking tot de laatste toestand wordt opgemerkt dat in geval van wijziging, c.q. uitbreiding enlof verandering, een produkt tijdelijk opnieuw in een ontwikkeltoestand verkeert. We bespreken in deze paragraaf twee hoofdtoestanden. We onderscheiden de toestanden van een produkt vóór oplevering en de toestanden ná oplevering. We refereren daarbij aan een indeling in soorten beheersing zoals die is beschreven door van Genochten et al (1993). Deze indeling is gebaseerd op geconstateerde verschuivingen van ,beheersing van : het ontwikkelwerk binnen de software-industrie.

78

Hoofdstuk 5 De toestanden van een produkt v66r oplevering Projectbeheersing richt zich op de beheersing van alleen het ontwikkelwerk vanaf het vastleggen van eisen tot en met de constructie (de bouw en de invoering) van een produkt. Met (Baslli en Rombach 1988) en (Bush en Fenton 1990) stellen we dat alle deel- en tussenprodukten onderwerp kunnen zijn van kwaliteitsmetingen. Voorbeelden van tussenprodukten zijn conceptuele gegevensmodellen, programma-ontwerpen, code, databasestructuren etcetera. In overleg met een projectleider dienen afnemers afspraken te maken over de tijdstippen waarop (deel)produkten moeten worden opgeleverd en de produktkwaliteit moet worden gecontroleerd. De kwaliteit van een produkt dient tijdens het ontwikkelwerk te worden bewerkstelligd.

Makers trachten zo goed mogelijk specificaties te vertalen in kenmerken van een informatiesysteem. Tussentijds moeten controles (verificaties en validaties) verricht kunnen worden op de verschillende deel- en tussenprodukten. Afhankelijk van de intensiteit waarmee afnemers participeren in het ontwikkelwerk bepalen zij mede de produktkwaliteit.

De toestanden van een produkt ná oplevering Makers en afnemers kunnen het zich niet langer veroorloven slechts oog te hebben voor alleen de uitgaven van ontwikkeling. Ontwikkelorganisaties zullen zich ook verantwoordelijk moeten gaan voelen voor het onderhoud van de software die zij ontwikkelen (van Genuchten et al 1993). Dit betekent dat het beheersen van softwareontwikkeling niet alleen meer het binnen tijd en tegen overeengekomen kosten opleveren van een produkt betreft (projectbeheersing genoemd), maar dat beheersing zich uitstrekt over de levenscyclus van een produkt (inclusief onderhoud, wijziging en uitbreiding). Dit soort beheersing wordt produktbeheersing genoemd. Belangrijkste verschil ten opzichte van projectbeheersing is de doorlopende betrokkenheid en verantwoordelijkheid, tijdens het ontwerpen, exploiteren en beheren, van de ontwikkelorganisatie voor te ontwikkelen informatiesystemen. Produktbeheersing omvat de beheersing van de toestanden van produkten zowel voor als na overdracht aan de afnemer. Wanneer men verantwoordelijk is voor toestanden van een softwareprodukt na oplevering wordt produktkwaliteit onder meer bepaald door zaken zoals de begeleiding en de bewaking van de invoering, het opstellen van service-level overeenkomsten, het periodiek verzorgen van 'updates' (nieuwe versies), etcetera. Samenvatting Een softwareprodukt of informatiesysteem doorloopt bepaalde toestanden tijdens een levenscyclus. Afhankelijk van de toestanden die een produkt doorloopt en waarvoor men verantwoordelijk is varieert de betekenis van produktkwaliteit. We onderscheiden de volgende produkttoestanden en beschrijven daarbij telkens kort aan de hand van voorbeelden de betekenis van produktkwaliteit.

79

Produktkwaliteit een produkt tijdens ontwikkeling: produktkwaliteit wordt bepaald door de mogelijkheid controles (verificaties en validaties) uit te voeren op deel- en tussenprodukten een produkt tijdens invoering: produktkwaliteit is in belangrijke mate afhankelijk van zaken zoals instructies, voorlichtingen en opleidingen een produkt tijdens exploitatie: produktkwaliteit wordt bepaald door de geboden service aan gebruikers, bijvoorbeeld met betrekking tot het verhelpen van storingen, het leveren van nieuwe versies etcetera. een produkt tijdens transitie: produktkwaliteit hangt samen met de mogelijkheden om een produkt te veranderen en te verbeteren Binnen de dimensie van de toestanden van een produkt verandert de omschrijving van een produkt en daarmee de betekenis van produktkwaliteit Opgemerkt dient te worden dat het doorlopen van toestandveranderingen geen lineair proces hoeft te zijn. !1;1. geval van incrementele ontwikkeling worden de bovengenoemde toestanden afzonderlijk voor deelsystemen (ofwel incrementen) doorlopen. Bij prototyping worden de bovengenoemde toestanden een aantal keren in een kort tijdsbestek doorlopen. Men dient er zich dan rekenschap van te geven dat men met zich elkaar afwisselende betekenissen van produktkwaliteit te maken heeft.

5.4.3 De uniekheid van een produkt De markt stelt steeds hogere eisen aan de software-industrie. Naast· een toenemende complexiteit van informatiesystemen ontstaan nieuwe toepassingsgebieden. Ook wordt integratie van afzonderlijke informatiesystemen in toenemende mate gewenst of vereist. De software-industrie tracht hier een antwoord op te vinden door infortnatiesystemen in toenemende mate te standaardiseren en te modulariseren (van Genuchten et al 1993). Door modularisatie van informatiesystemen en standaardisatie van modules wordt hergebruik van eerder gedaan weik mogelijk. Doel van hergebruik i is om met een gelimiteerd aantal basiscomponenten een zo breed mogelijk assortiment te kunnen samenstellen waarmee tegemoet wordt gekomen aan de wensen van een markt maar ook van individuele afnemers. Duidelijk is dat niet aan alle specifieke eisen van afnemers kan worden voldaan. Redenen voor afnemers specifieke eisen te laten vallen in ruil voor standaardoplossingen zijn een kortere doorlooptijd, lagere kosten en meer mogelijkheden voor integratie met andere produkten. Hergebruik van eerder gedaan werk is als ontwikkelactiviteit verwant met het ontwikkelaspect leren en veranderen. Immers, essentieel voor leren en veranderen is het hergebruik van kennis en ervaring. Van 'eerder gedaan weik' bestaan inmiddels vele definities. Bijvoorbeeld in (Biggerstaff en Perlis 1989) wordt onderscheid gemaakt in hergebruik van kennis (bijvoorbeeld referentiemodellen), en in hergebruik van ~Ie componenten (bijvoorbeeld programmaprocedures, database-structuren, mensmachinedialo-

80

Hoofdstuk 5 gen etcetera). In (Trienekens en Kusters 1992) wordt onderscheid gemaakt in herbruikbare produkt- en procescomponenten. Voorbeelden van procescomponenten zijn: levenscyclusmodellen (bijvoorbeeld: lineair, incrementeel, prototyping) maar ook gedetailleerde activiteitenstructuren (bijvoorbeeld voor het normaliseren van gegevensstructuren). Afhankelijk van de standaards die worden gebruikt bij de ontwikkeling van een produkt en de mate waarin gebruik wordt gemaakt van standaardmodules noemen we in dit boek een produkt meer of minder uniek. We merken op dat een standaard eindprodukt uiteraard wel een bepaalde mate van uniekheid kan hebben op grond van de specifieke wijze waarop het is samengesteld uit standaardcomponenten. We bespreken in het navolgende twee uitersten met betrekking tot de uniekheid van een produkt, te weten het specifieke en het standaard informatiesysteem.

Specifieke informatiesystemen Met een specifiek informatiesysteem wordt hier een informatiesysteem bedoeld dat niet gestandaardiseerd is en waarbij (vrijwel) geen gebruik is gemaakt van reeds eerder ontwikkelde componenten of modulen. Getracht is dit systeem zo volledig mogelijk toe te snijden op de specifieke eisen van een afnemer. Een specifiek informatiesysteem is in zijn meest extreme vorm een uniek produkt Er bestaat noch een duplicaat, noch een tweede soortgelijk systeem. De ontwikkeling van een dergelijk informatiesysteem is sterk afnemerafhankelijk. Een afnemer wordt intensief betrokken bij het specificeren, verifiëren en valideren van tussen- en eindprodukten. Hergebruik van eerder gedaan werk vindt plaats op basis van wat in de hoofden van makers aanwezig is als kennis en ervaring. Het ontwikkelen van specifieke informatiesystemen kan worden omschreven als het verkopen van puur produktie- of ontwikkelcapaciteit door makers aan afnemers (Trienekens en Kusters 1992). Dit soort makers zijn veelal niet gespecialiseerd in bepaalde typen informatiesystemen. In minder extreme vormen van specifieke informatiesystemen worden referentiemodellen gebruikt als uitgangspunt en referentiekader. Referentiemodellen hebben betrekking op verschillende aspecten (gegevens, processen, gedrag) van de informatievoorziening enlof weerspiegelen de informatievoorziening van bepaalde typen bedrijven of bedrijfstakken (Greveling 1990). Het criterium voor produktkwaliteit van specifieke systemen is maximale tevredenheid bij de afnemer. Functionele en technische onvolkomenheden kunnen acceptabel zijn voor makers mits de tevredenheid van de afnemer daar niet onder lijdt Een systeem als aangenaam ervaren is voor afnemers vaker bepalend voor de kwaliteit dan de (technische) perfectie van de structuur en de componenten van een informatiesysteem. Door allerlei, soms niet-gespecificeerde, extra's wordt getracht de kwaliteit te verhogen. Dit kan variëren van het zo volledig mogeliJK aansluiten van een informatiesysteem op specifieke handmatige procedures binnen een bedrijfssituatie tot het vergroten van de aantrekkelijkheid van het produkt door het aanbrengen van 'toeters en bellen' (bijvoorbeeld door extra aandacht te besteden aan de mensmachine-interface).

81

Produktkwaliteit Standaard informatiesystemen Standaard informatiesystemen beschrijven we hier als informatiesystemen die in meerdere soortgelijke bedrijfssitaties (bijvoorbeeld bedrijfsbranches. bedrijfstypen. bedrijfsfunctietypen) kunnen worden toegepast. Makers van standaard informatiesystemen beperken zich over het algemeen tot bepaalde produktfamilies. Produkten zijn opgebouwd uit componenten (bijvoorbeeld softwaremodulen) die zoveel mogelijk zijn gestandaardiseerd. Op basis van deze standaardisatie kan tegen een lagere prijs en een kortere doorlooptijd een gewenst produkt worden samengesteld (geassembleerd). Als beperking geldt dat specifieke wensen of eisen ten aanzien van een informatiesysteem niet worden gehonoreerd. Makers zullen in dit soort ontwikkelwelk stetk gericht zijn op het afnemeronafhankelijk (matktafhankelijk) ontwikkelen van componenten van informatiesystemen met het oog op hergebruik. Meerdere eindprodukten kunnen parallel aan elkaar worden ontwikkeld, zoveel als mogelijk gebaseerd op dezelfde basiscomponenten. De beheersvorm die hierbij hoort wordt door van Genuchten et al (1993) multiproduktbeheersing genoemd. We merken op dat er verschillende vormen van standaard informatiesystemen zijn. Bijvoorbeeld een softwarepakket dat parametriseerbaar is binnen een bepaalde bedrijfssituatie voor een bepaald soort produktiebesturing of een softwarepakket dat als infrastructurele component organisatiebreed wordt verspreid (bijvoorbeeld tekstverwetkingspakketten. spr~adsheetpakketten etcetera}. Het criterium voor produktkwaliteit van standaard systemen is de mate waarin is gestandaardiseerd en de mate waarin een softwareprodukt is opgebouwd uit goed afgebakende modulen. Functionele en technische perfectie en de mogelijkheid tot integratie met andere informatiesystemen heeft een veel hogere prioriteit dan het voldoen aan specifieke wensen en eisen van afnemers. Samenvatting Ook in deze produktdimensie geldt dat een grens (hier tussen specifiek en standaard} niet scherp te trekken is. Ook de uniekheid van een produkt verloopt gradueeL Wanneer hergebruik als criterium wordt genomen dan kan onderscheid worden gemaakt tussen produkten waarbij alleen hergebruik van kennis plaatsvindt (bijvoorbee'd op grond van kennis en ervaring in de hoofden van mensen). produkten die zijn gebaseerd op referentiemodellen. en produkten die zijn gebaseerd op hergebruik van fysieke componenten (Trienekens en Kusters 1992}. We onderscheiden enkele vormen van uniekheid van produkten waarbij telkens voorbeelden worden geven van de betekenis van produktkwaliteit een specifiek produkt: produktkwaliteit is afhankelijk van de mate waarin een produkt is toegesneden op de specifieke eisen en wensen van een klant

82

Hoofdstuk 5 een produkt gebaseerd op referentiemodellen: produktkwaliteit is gebaseerd op onder andere een gemeenschappelijke terminologie en datastructuur (onder meer daardoor is aanpassing en gestructureerde uitbreiding mogelijk) een produkt als standaardpakket: produktkwaliteit is afhankelijk van de mogelijkheden en de mate waarin eerder gedaan werk kan worden hergebruikt en waarin produkten zijn opgebouwd uit (generieke) standaardmodules

Conclusies Informatiesystemen en softwareprodokten kunnen op verschillende manieren worden omschreven. Dit is duidelijk geworden aan de hand van beschrijvingen binnen de volgende drie dimensies: ~ de scope van een produkt De produktscope betreft een afbakening van een informatiesysteem ten opzichte van zijn omgeving. Voorbeelden van deze afbakening zijn respectievelijk: het produkt beperkt tot programmatuur of code. het produkt als informatiesysteem met bijbehorende procedures. en het produkt informatie zoals dat wordt verstrekt door een systeem. ~ de toestanden van een produkt De produkttoestand betreft de verschillende toestanden van een informatiesysteem die dat systeem doorloopt Voorbeelden zijn respectievelijk: de verschillende toestanden van een produkt vóór invoering. de verschillende toestanden van een produkt tijdens invoering en de verschillende toestanden van een produkt ná invoering. ~ de uniekheid van een produkt De produktuniekheid betreft de mate van uniekheid van een informatiesysteem ten opzichte van eerder gedaan werk. Voorbeelden van verschillende vormen van uniekheid zijn respectievelijk: volledige nieuwe afnemerspecifieke produk:ten. afnemerspecifieke produkten gebaseerd op referentiemodellen en produkten die uitsluitend zijn gebaseerd op standaardcomponenten (bijvoorbeeld nieuwe versies of releases van een standaardprodukt).

Voor elke dimensie hebben we twee produktuitersten van informatiesystemen of softwareprodukten beschreven. Doel was om daarmee duidelijk te maken dat de betekenis van produktkwaliteit per produktomschrijving verschilt. Op grond hiervan breiden we de conceptstructuur van produktkwaliteit volgens (Serc~Quint 1992) als volgt uit (zie figuur 5.3).

83

Produktkwaliteit

Figuur 5.3: Produk:tscope, produkttoestand en produktuniekheid in de conceptstructuur We merken op dat evenals de begrippen indicator en meetvoorschrift de produktkarakteristieken op zich geen betrekking op kwaliteit hoeven te hebben. Echter, met name in relatie tot het begrip eigenschap Oees: kwaliteitseis) vonnen deze begrippen een belangrijke basis voor de afleiding van produktkwaliteitseisen.

5.5 Produktkarakteristieken geven indicaties voor produktkwaHteitseisen: een toepassing In deze paragraaf wordt de toepasbaarheid van het begrip produktkarakteristieken gedemonstreerd. Uitgangspunt is de verzameling produktkwaliteitseisen volgens (Bemelmans 1991 ). Aan de hand van de drie dimensies scope, toestanden en uniekheid van een produkt wordt aangetoond dat de relevantie van kwaliteitseisen samenhangt met het type produkt dat wordt ontwikkeld. In paragraaf 5.5.1 introduceren we een opsomming van produktkwaliteitseisen. Paragraaf 5.5.2 laat een differentiatie zien in die opsomming van kwaliteitseisen over de drie produktdimensies.

5.5.1 KwaHteftseisen volgens (Bemelmans 1991) In (Bemelmans 1991) worden 12 hoofdkwaliteitseisen opgesomd en beschreven. Een aantal van deze kwaliteitseisen zijn verder onderverdeeld, zie tabel 5.1. De opsomming is gebaseerd op praktijkervaring en literatuur (Boehm 1978, Delen en Rijsenbrij 1990a, 1990b, Gilb 1988, Watts 1987, Willmer 1985). We merken op dat in andere opsommingen van kwaliteitseisen in de literatuur soms andere definities van kwaliteitseisen worden gegeven. Vrijwel altijd zijn deze definities terug te voeren op de kwaliteitseisen in de navolgende tabel.

84

Hoofdstuk 5

KW ALlTElTSEIS

BESCHRUVING

tijdigheid

wordt onderverdeeld in drie deeleisen, nL responsiesnelheid, frequentie van informatieverstrekking en bewaartijd van gegevens responsiesnelheid is de snelheid waarmee een systeem aangeboden transacties atbandelt frequentie van informatieverstrekking heeft betrekking op bet aantal keren per tijdseenheid waarmee informatie wordt verstrekt bewaartijd van gegevens heeft betrekking op de duur dat gegevens opgeslagen kunnen blijven (totdat zij hun geldigheid verliezen) wordt onderverdeeld in drie deeleisen, nl. juistheid, volledigheid en betrouwbaarheid juistheid heeft betrekking op de mate waarin een systeem correct werkt volledigheid heeft betrekking op de mate waarin invoer in een keer correct wordt verwerkt betrouwbaarheid wordt weer onderverdeeld in bedrijfszekerheid en beschikbaarheid; respectievelijk hebben deze deeleisen betrekking op de mate waarin storingen en uitval worden voorkomen en de mate waarin een systeem beschikbaar is naar tijd en plaats de mate waarin een systeem is beveiligd tegen ongeoorloofd gebruik de mate waarin tijdens de ontwikkeling van een systeem afwegingen zijn gemaakt tussen enerzijds te realiseren eisen en anderzijds kosten en inspanningen (balanceren) de mate waarin een systeem daadwerkelijk ondersteuning biedt aan taken van een gebruiker wordt onderverdeeld in de deeleisen Jeerbaarbeid en bruikbaarheid Jeerbaarbeid heeft betrekking op de tijd die nodig is voor een gebruiker om zich het systeem eigen te maken bruikbaarheid heeft te maken met het gemak (o.a afhankelijk van de benodigde tijd) waarmee men het systeem kan gebruiken de mate waarin een systeem zonder aanpassingen van ontwerpers kan blijven functioneren in een bedrijfssituatie die aan veranderingen onderhevig is wordt onderverdeeld in de deeleisen onderhoudbaarheid, aanpasbaarheid, uitbreidbaarheid en overdraagbaarheid onderhoudbaarbeid en aanpasbaarbeid bebben betrekking op de mate waarin fouten kunnen worden hersteld of wijzigingen kunnen worden aangebracht (bijvoorbeeld vervanging van apparatuur) uitbreidbaarheid heeft te maken met de mogelijkheden om een systeem van nieuwe functionaliteit en prestaties te voorzien overdraagbaarbeid is de mate waarin het mogelijk is programmatuur over te plaatsen naar andere machineconfiguraties de mate waarin het mogelijk is de werking van een systeem te verifii!ren en te valideren de mate waarin een systeem vanuit bedrijfskundig perspectief ingepast kan worden in een bedrijfssituatie de mate waarin een systeem ingepast kan worden in de technische infrastructuur de mate waarin het systeem of delen daarvan kunnen worden toegepast bij nieuwe ontwikkelprojecten of in nieuwe toepassingen

integriteit

beveiliging (security) doelmatigheid

effectiviteit gebruiksvriendelijkheid

flexibiliteit in enge zin

flexibiliteit in brede zin

testbaarheid integreerbaarbeid inpasbaarbeid herbruikbaarheid

Tabel 5.1 Kwaliteitseisen volgens (Bemelmans 1991)

85

Produktkwaüteit Als voorbeeld noemen we de kwaliteitseis 'robuustheid'. Robuustheid heeft betrekking op de mate waarin een softwareprodukt bestand is tegen veranderingen in de omgeving of tegen foutief gebruik van het produkt. Robuustheid is in deze betekenis terug te voeren op de kwaliteitseisen 'flexibiliteit in enge zin' en 'flexibiliteit in brede zin' in bovenstaande tabel Verder merleen we op dat in bovenstaande tabel verkorte definities worden gehanteerd. Voor een meer volledige beschrijving van de eisen en onder andere de maatregelen die moeten worden genomen om de eisen te realiseren wordt verwezen naar (Bemelmans 1991). Het zonder meer voorleggen aan afnemers van een dergelijke opsomming van kwaliteitseisen met de vraag of zij de voor hen relevante kwaliteitseisen willen aangeven heeft weinig kans van slagen. Dit is reeds eerder in de literatuur gesteld door onder meer (Evans en Marciniak 1987). Ondersteuning van afnemers bij het specificeren van de meest relevante kwaliteitseisen is van belang daar het realiseren van alle kwaliteitseisen een ondoenlijke zaak is; niet alleen op grond van technische mogelijkheden maar ook vanwege de hoge kosten die daarmee gepaard gaan. In de navolgende paragraaf wordt beschreven welke indicaties de verschillende produktomschrijvingen binnen de produktdimensies geven voor de relevantie van kwaliteitseisen.

5.5.2 Prodokdimensies en produktkwaliteitseisen In deze paragraaf worden relaties beschreven tussen de kwaliteitseisen uit tabel 5.1 en produktomschrijvingen op de drie dimensies van de scope, de toestanden en de uniekheid van een produkt. Binnen elke produktdimensie worden drie produktomschrijvingen gegeven met voorbeelden van kwaliteitseisen. We geven telkens per produktdimensie een korte toelichting. In tabel 5.2 is voor de dimensie van de produktscope gekozen voor drie verschillende scopes van een softwareprodukt · PRODUKTSCOPE

KWALITEITSEISEN

software 'op zich'

integriteit tijdigheid integriteit tijdigheid gebruiksvriendelijkheid integriteit tijdigheid gebruiksvriendelijkheid beveiliging (security) effectiviteit

software plus documentatie

informatiesysteem

Tabel 5.2 Kwaliteitseisen in relatie tot de scope van een produkt De scope verschuift van 'software op zich' naar een informatiesysteem. We geven een

korte toelichting. Allereerst merken we op dat de relevantie van een aantal kwaliteitseisen

86

Hoofdstuk 5

invariant is voor de produktomschrijvingen in de dimensie van de produktscope. In de tabel zijn als voorbeelden opgenomen de kwaliteitseisen integriteit en tijdigheid. Dit betekent dat aanvullende informatie over een 'produkt' nodig is om uitspraken te kunnen doen over de relevantie van deze kwaliteitseisen. Uiteraard gelden er minimumnonnen op grond van vanzelfsprekende behoeften van afnemers of algemeen geaccepteerde normen. Echter, op basis van de produktomschrijvingen kunnen geen uitspraken worden gedaan over de relevantie (lees: het dwingende of noodzakelijke karakter) van deze kwaliteitseisen. We komen in hoofdstuk 7 terug op de vraag welke aanvullende infonnatie noodzakelijk is om de relevantie van kwaliteitseisen zoals integriteit en tijdigheid te kunnen bepalen. Daarnaast is te zien in tabel 5.2 dat de scope van een produkt indicaties geeft voor de relevantie van bepaalde kwaliteitseisen. Bij een softwareprodukt met een beperkte scope geldt als uitgangspunt dat de relaties die het produkt heeft met de bedrijfsomgeving, bijvoorbeeld het soort gebruik, het type gebruiker, het type procedures etcetera niet nader zijn gespecificeerd. Hoewel een groot aantal van de kwaliteitseisen volgens Dernelmans van belang kunnen zijn kan dit niet worden afgeleid uit de omschrijving 'software op zich'. Voor een produkt met een bredere scope, bijvoorbeeld wanneer de aansluiting op handmatige procedures, gebruiksricbtlijnen etcetera worden meegenomen als onderdeel van het produkt, is een kwaliteitseis zoals gebruiksvriendelijkheid van belang. Wenst men een softwareprodukt als een informatiesysteem te zien (bijvoorbeeld een systeem ingepast in een bedrijfsomgeving) dan geeft dit indicaties voor de relevantie van weer andere kwaliteitseisen. Bijvoorbeeld geldt dit voor de kwaliteitseis effectiviteit (van de informatie die wordt geproduceerd) om bedrijfsdoelstellingen te realiseren en de kwaliteitseis beveiliging van het systeem tegen ongeoorloofd gebruik. Binnen de produktdimensie van de produkttoestanden hanteren we eveneens drie omschrijvingen van produkttoestanden, zie tabel 5.3.

PRODUKTTOESTANDEN

KWALITEITSEISEN

een produkt voor oplevering een produkt tijdens invoering

doelmatigheid doelmatigheid testbaarheid gebruiksvriendelijkheid (!eerbaarheid) integreerbaarbeid inpasbaarbeid doelmatigheid testbaarheid gebruiksvriendelijkheid integreerbaarbeid inpasbaarbeid onderhoudbaarheid flexibiliteit overdraagbaarheid

een produkt tijdens exploitatie en transitie

Tabel 5.3 Kwaliteitseisen in relatie tot de toestanden die een produkt doorloopt

87

Produktkwaliteit De produktomschrijving verschuift van een produkt waarvan alleen de toestanden worden beschouwd tot aan oplevering, via een produkt tot en met invoering, naar een produkt tot en met exploitatie en/of evolutie in een andere generatie. Ook in deze tabel zijn kwaliteitseisen gegeven die op grond van een produktomschrijving relevant zijn. Daarnaast bevat tabel 5.3 de kwaliteitseis doelmatigheid waarvan de relevantie invariant is voor de produktomschrijvingen. Uiteraard geldt ook hler weer dat voor deze kwaliteitseis aan minimumnormen moet worden voldaan. Echter, op basis van de produktomschrijvingen kunnen niet expliciet uitspraken worden gedaan over de relevantie (lees: het dwingende of noodzakelijke karakter) van de kwaliteitseis doelmatigheid. We komen daarop terug in hoofdstuk 7. Tabel 5.3 laat verder voorbeelden zien van kwaliteitseisen die met name relevant zijn voor een bepaalde produktomschrijving. We lichten dit kort toe. Wanneer door ontwikkelaars alleen de verantwoordelijkheid wordt gedragen voor produkttoestanden tot aan oplevering behoeft bij de ontwikkeling van dat produkt veelal niet expliciet te worden geanticipeerd op specifieke eigenschappen van dat produkt met betrekking tot invoering, onderhoud en uitbreiding. Het is niet mogelijk om op grond van alleen deze produktomschrijving bepaalde kwaliteitseisen als relevant te beschouwen. Indien tevens verantwoordelijkheid wordt gedragen voor het invoeringstraject als produkttoestand worden kwaliteitseisen relevant zoals gebruiksvriendelijkheid (bijvoorbeeld !eerbaarheid), integreerbaarbeid en testbaarheid (met name het gezamelijk met gebruikers testen van een informatiesysteem binnen de bedrijfssituatie). Indien afnemers een produkt wensen dat goed beheerd kan worden en geschikt is voor verdere (evolutionaire) ontwikkeling dan worden naast de eerder genoemde kwaliteitseisen, de eisen zoals flexibiliteit (zowel in enge, als in brede zin) en overdraagbaarheid relevant. Ook binnen de dimensie van de uniekheid van een produkt hanteren we drie produktomschrijvingen. Tabel 5.4 toont per produktomschrijving enkele relevante kwaliteitseisen. PRODUKTUNIEKHEID

KW.AUI'EITSEISEN

een specifiek produkt

gebruiksvriendelijkheid effectiviteit testbaarheid onderhoudbaarheid flexibiliteit testbaarheid onderhoudbaarheid herbruikbaarheid overdraagbaarheid

een produkt gebaseerd op referentiemodellen een standaardprodukt

Tabel5.4: Kwaliteitseisen in relatie tot de uniekheid van een produkt De beide produktuitersten kunnen worden omschreven als respectievelijk afnemerspecifieke en standaardprodukten. Tussen deze uitersten kunnen softwareprodukten worden

88

Hoofdstuk 5 onderscheiden die gebaseerd zijn op een referentiemodel. De tabel laat kwaliteitseisen zien die met name relevant zijn voor een bepaalde produktomschrijving. We merken op dat in deze tabel geen voorbeelden worden gegeven van kwaliteitseisen waarvan de relevantie invariant is voor de drie produktomschrijvingen. We geven een korte toelichting bij de tabel. Indien kenmerken van een specifieke bedrijfssituatie het uitgangspunt dienen te zijn voor de ontwikkeling van een softwareprodukt, bijvoorbeeld individuele gebruikerswensen of unieke organisatiebehoeften, dan zijn met name relevant de kwaliteitseisen gebruiksvriendelijkheid en de effectiviteit (van de informatie die verstrekt dient te worden). In geval men zich richt op een grote verzameling (potenti15le) klanten of een markt dan zijn kwaliteitseisen zoals onderhoudbaarheid, testbaarheid en herbruikbaarheid van belang. In deze situatie worden veelal softwareprodukten in versies geproduceerd voor een anonieme markt. Gestreefd wordt naar perfecte (foutloze) en testbare en onderhoudbare produkten. Centraal staat het ontwikkelen van produkten binnen bepaalde produktfamilies door middel van het assembleren van (herbruikbare) componenten. Ook aan de overdraagbaarheid dienen hoge eisen te worden gesteld daar een standaardprodukt vaak binnen verschillende hardwareomgevingen moet kunnen functioneren. Conclusies Deze paragraaf heeft laten zien dat het onderscheid in drie dimensies van een softwareprodukt leidt tot een differentiatie in een opsomming van kwaliteitseisen. Daarmee kan aan makers en afnemers een houvast worden geboden voor wat betreft het bepalen van de relevantie van kwaliteitseisen voor een bepaald type produkt. We merken nogmaals op dat de relevantie van sommige kwaliteitseisen invariant is voor de produktomschrijvingen op de drie dimensies. Als voorbeelden zijn genoemd de kwaliteitseisen tijdigheid en integriteit binnen de scopedimensie en de kwaliteitseisen testbaarheid en doelmatigheid binnen de dimensie van de produkttoestanden. We komen hierop terug in hoofdstuk 7 wanneer we verder ingaan op een methode voor het specificeren van kwaliteitseisen. Daar zal blijken dat naast de bepaling van de gewenste karakteristieken van een softwareprodukt op drie dimensies voor enkele kwaliteitseisen een aanvullende analyse noodzakelijk is.

5.6 Samenvatting en conclusies In de literatuur is het begrip produktkwaliteit op verschillende wijzen uitgewerkt. In dit hoofdstuk zijn de onderliggende begrippen van produktkwaliteit die daarbij worden gehanteerd beschreven. Aangegeven is dat de definities van produktkwaliteit volgens de ISO-standaard een beperkt beeld geven van produktkwaliteit Tevens zijn beperkingen aangetoond van recente uitwerkingen van het begrip produktkwaliteit. De beperkingen hebben met name betrekking op het feit dat produktkwaliteit voornamelijk 'product based' (in tegenstelling tot 'user based') wordt uitgewerkt. Produktkwaliteit blijft daarmee voor een belangrijk deel buiten het gezichtsveld van afnemers. In dit hoofdstuk geldt als uitgangspunt dat uitspraken over noodzakelijke en gewenste

89

Produktkwaliteit kwaliteit van een softwareprodukt eerst kunnen worden gemaakt wanneer duidelijk is wat wordt bedoeld met een produkt. Informatiesystemen en softwareprodukten kunnen worden beschreven aan de hand van drie dimensies, te weten de dimensie van de scope, de dimensie van de toestanden en de dimensie van de uniekheid van een produkt. Door uiterste vormen van produkten, qua betekenis en definitie, binnen elke dimensie te beschrijven wordt aangetoond dat de relevantie van kwaliteitseisen afhankelijk is van het soort produkt. Om verbetering te brengen in het begrip produktkwaliteit is een conceptstructuur van produktkwaliteit volgens Serc-Quint (1992) uitgebreid. Respectievelijk zijn toegevoegd de begrippen produktscope, produkttoestand en produktuniekheid. Deze begrippen richten de afnemer en de ontwikkelaar op een beschrijving van de karakteristieken van een te ontwikkelen informatiesysteem op drie dimensies. De bruikbaarheid van de geïntroduceerde begrippen is vervolgens gedemonstreerd door met behulp van het onderscheid in drie produktdimensies een differentiatie aan te brengen in een verzameling kwaliteitseisen. In hoofdstuk 7 wordt hiervan gebruikt gemaakt bij de ontwikkeling van een methode voor het specificeren van kwaliteitseisen.

Dit hoofdstuk is voomarnelijk gericht op de inhoudelijke aspecten (het Wat) van produktkwaliteit In hoofdstuk 6 richten we ons op kwaliteit van ontwikkelprocessen en -middelen, c.q. het Hoe en Waarmee van het ontwikkelwerk:.

90

6

PROCES· EN MIDDELENKWALITEIT

6.1 Inleiding Nadat in het voorgaande hoofdstuk produktkwaliteit centraal heeft gestaan richten we ons nu op de kwaliteit van processen en middelen. Proces- en middelenkwaliteit zijn begrippen die pas de laatste jaren meer aandacht krijgen. De opvatting wint terrein dat het bewerkstelligen van kwaliteit niet beperkt kan blijven tot het stellen van produkteisen voorafgaand aan de ontwikkeling en het na afloop controleren of aan die eisen is voldaan. Zaak is het ontwikkelwerk zodanig in te richten dat kwaliteit wordt ingebouwd in een produkt naarmate de ontwikkeling vordert (ISO 9000-3 1991). Dit vraagt om extra aandacht voor ontwikkelprocessen en de middelen die worden toegepast in het ontwikkelwerk. In dat kader dient naast produktkwaliteit aandacht te worden besteed aan proces- en middelenkwaliteit Vraag is echter wat precies moet worden verstaan onder proces- en middelenkwaliteit Wanneer men eenzelfde benadering kiest als voor produktkwaliteit dient men vragen te beantwoorden zoals: 'welke kwaliteitseisen kunnen worden gesteld aan processen en middelen', 'waarvan en hoe kunnen deze kwaliteitseisen worden afgeleid', en: hoe kan worden gemeten of aan de gestelde eisen is voldaan? Zoals reeds is aangegeven in hoofdstuk 4 staat in de software-industrie de defmiëring van proces- en middeleneisen en de roetrieken daarvoor nog in de kinderschoenen (Fenton 1991). Hoofdreden is dat vooralsnog weinig inzicht bestaat in het ontwikkelwerk. Dit hoofdstuk richt zich daarom niet op de identificatie van kwaliteitseisen voor processen en middelen. Het accent ligt op een beschrijving van de soorten processen en de soorten middelen die in het ontwikkelwerk kunnen worden onderscheiden. Eerst wanneer daarvan een duidelijk beeld bestaat kunnen uitspraken worden gedaan over de betekenis van de begrippen proces- en middelenkwaliteit In dat verband geldt in dit hoofdstuk het adagium: 'weten voordat kan worden gemeten'. De structuur van dit hoofdstuk is als volgt. In paragraaf 6.2 worden eerst kort de uitgangspunten gegeven voor de nadere beschrijving van processen en middelen. De paragrafen 6.3 tot en met 6.5 beschrijven respectievelijk processen en middelen voor het modelleren, het beheersen, en leren en veranderen. Daarbij wordt gebruik gemaakt van het onderscheid in verschillende soorten prodokten (qua scope, toestanden en uniekheid). Voor processen wordt beschreven welk soort voorschriften moet worden gehanteerd om proceskwaliteit te kunnen bewerkstelligen. Voor middelen wordt ingegaan op wat zij afdekken in het ontwikkelwerk. Paragraaf 6.6 sluit dit hoofdstuk af met een samenvatting en conclusies.

6.2 Wat moet worden verstaan onder processen en middelen van systeemontwikkeling, en wat betekent kwaliteit daarvan ? In deze paragraaf beschrijven we de uitgangspunten voor proces- en middelenkwaliteit zoals die worden gehanteerd in het vervolg van dit hoofdstuk.

91

Proces- en middelenkwaliteit

6.2.1 Processen en proceskwaliteit In dit boek wordt uitgegaan van systeemontwikkeling als een complex geheel van uitvoerende, besturende en leer- en veranderingsprocessen (zie hoofdstuk 3: het ontwikkelaspectenmodel). In de literatuur wordt recent gesteld dat voorschriften en richtlijnen dienen te worden opgesteld om de kwaliteit van processen van systeemontwikkeling te kunnen plannen en controleren. Het geheel van procedures en richtlijnen voor kwaliteitszorg en -borging staat bekend onder de naam kwaliteitssysteem. Veel organisaties trachten hun ontwikkelwerk te verbeteren door de ontwikkeling en de certificering van kwaliteitssystemen (Rienstra 1991). Naast deze procedurele en op standaardisatie gerichte aanpak van het proces krijgt recent een andere benadering van proces- en middelenkwaliteit in literatuur en praktijk veel aandacht. In deze benadering wordt getracht zowel proces- als middelenkwaliteit uit te drukken in bepaalde eigenschappen (Humphrey 1989, Bush en Fenton 1990, Pfleeger 1993, Basili 1993). Vervolgens dient door metingen te worden aangetoond of aan bepaalde eigenschappen wordt voldaan. Zoals gesteld richten we ons in dit hoofdstuk niet op het verrichten van metingen aan processen en middelen, eerst dient inzicht te ontstaan in de verschillende soorten processen. Vanuit dit inzicht kan worden gestreefd naar proceskwaliteit. De eigenschappen van processen die we in dit hoofdstuk hanteren baseren we op procesomschrijvingen volgens het groeimodel van Humphrey (1989). Door deze auteur worden vijf niveaus van procesvolgroeidbeid onderscheiden. Respectievelijk zijl'\ dit de niveaus 'initieel', 'herhaalbaar', 'defmieerbaar', 'beheersbaar' en 'optimaliseerbaar'. De eigenschappen van processen van een organisatie die zich bevindt op het initii!le niveau kunnen worden omschreven als ad hoc en chaotisch. Op het herhaalbare procesniveau heeft een organisatie stabiliteit in de procesvoering bewerkstelligd. Processtabiliteit heeft alleen betrekking op een bepaald soort werk waarin men enige ervaring heeft opgebouwd en niet het ontwikkelen van geheel andere of nieuwe produkten. Op het niveau van een definieerbare procesvoering kan een organisatie het ontwikkelwerk beschrijven en beschikt zij over een basis om het volledig te begrijpen. Het niveau van beheersbaarheid houdt voor een organisatie de mogelijkheid in om op gestructureerde wijze ervaringsgegevens vast te leggen met het oog op het aanbrengen van verbeteringen, met name in de prodokten die worden ontwikkeld. Eerst op het optimaliseerbare niveau kan een organisatie vastgelegde ervaringsgegevens gebruiken om de procesvoering zelf te verbeteren. Afgeleid van het werk van Humphrey onderscheiden we in dit hoofdstuk vijf proceseigenschappen, te weten: herhaalbaarheid, definieerbaarheid, controleerbaarheid, bestuurbaarheid en verbeterbaarheid. De genoemde volgorde van deze eigenschappen of eisen is niet willekeurig maar komt in grote lijnen overeen met de niveaus van het groeimodel. Dit betekent dat proceseigenschappen zoals controleerbaarheid en bestuurbaarheid (c.q. beheersbaarheid) eerst mogelijk zijn wanneer de processen voldoen aan de eisen van herhaalbaarheid en defmieerbaarheid. (Structurele) verbeteringen in de procesvoering (c.q. optimaliseerbaarheid) zijn eerst mogelijk wanneer voldaan is aan de eisen van controleerbaarheid en bestuurbaarheid.

92

Hoofdstuk 6 In tegenstelling tot de grote opsomming van produktkwaliteitseisen in het voorgaande hoofdstuk betreft het hier dus slechts vijf kwaliteitseigenschappen (ofwel -eisen). Vrij vertaald naar het onderscheid in ontwikkelaspecten volgens Bemelmans (zie hoofdstuk 3) leggen wij in dit hoofdstuk de volgende relaties: de proceseigenschappen herhaalbaarheid en deflnieerbaarheid zijn met name van toepassing op de inhoudelijke ontwikkelprocessen, c.q. de modelleerprocessen; de proceseigenschappen controleerbaarheid en bestuurbaarheid zijn met name van toepassing op beheersprocessen, en de proceseigenschap verbeterbaarheid is met name van toepassing op leer- en veranderprocessen. In dit hoofdstuk worden ontwikkelprocessen nader beschreven en de wijze waarop deze verschillen met het type produkt dat wordt ontwikkeld. Om de genoemde kwaliteitseigenschappen te bewerkstelligen worden telkens voorschriften beschreven die dienen te worden opgesteld en te worden toegepast.

6.2.2 Middelen en middelenkwaliteit Middelen omvatten een veelsoortig scala aan zaken die kunnen worden ingezet of toegepast bij het ontwikkelwerk. Genoemd kunnen worden: personeel, methoden en technieken, en tools (zowel hardware als software). CASE-tools (Computer Aided Software Engineering) ofwel geautomatiseerde gereedschappen voor het ontwikkelwerk vormen in toenemende mate een belangrijke ondersteuning voor het ontwikkelwerk. Met name geldt dit voor de zogenaamde 'lower' CASE-tools die ontwerpondersteuning bieden, zoals programma- en databasegeneratoren (4GL). Voor wat betreft de 'upper' CASE-tools die met name analyseondersteuning bieden is de effectiviteit voor het ontwikkelwerk vooralsnog niet geheel duidelijk. Wel hebben verschillende empirische studies inmiddels aangetoond dat met 'upper'-CASE op deelgebieden (bijvoorbeeld de kwaliteit van de documentatie) verbeteringen worden bereikt, zie onder andere (Kusters en Wijers 1992). Onder meer als gevolg van enerzijds de tekortkomingen van deze tools zelf en anderzijds de invoeringsproblematiek in organisaties lijken fundamentele verbeteringen in het ontwikkelwerk zelf vooralsnog niet realiseerbaar (Stobart et al 1993). In dit hoofdstuk laten we CASE-tools buiten beschouwing wanneer we spreken over middelenkwaliteit Ook technische middelen als computerfaciliteiten, randapparatuur en technische communicatiefaciliteiten vallen buiten het kader van dit boek. De reden daarvan is tweeledig. Enerzijds is het gebied van geautomatiseerde gereedschappen en andere technische middelen te omvangrijk om in dit boek in één hoofdstuk te behandelen en anderzijds delen we met auteurs zoals onder andere Humphrey (1989) de opvatting dat eerst duidelijkheid dient te bestaan over de processen die moeten worden uitgevoerd, de methoden die daarbij worden gehanteerd en de mensen die daarbij een rol spelen voordat de benodigde geautomatiseerde middelen kunnen worden bepaald en kan worden gesproken over de kwaliteit daarvan. We maken in dit boek onderscheid tussen twee hoofdgroepen van middelen, te weten personele middelen en methoden.

93

Proces- en middelenkwaliteit Personele middelen worden in verschillende functies en voor verschillende talren ingezet bij het ontwikkelwerk. Een eerder in dit boek gemaakt onderscheid is dat tussen makers (bijvoorbeeld ontwerper of projectmanagers) en afnemers (bijvoorbeeld gebruikers, beheerders, opdrachtgevers). Om personele middelen te kunnen beschrijven hanteren we het NOlrapport 'Taken en Functies in de bestuurlijke informatica' (NOl 1993).

Methoden zijn middelen voor het gestructureerd ontwikkelen van informatiesystemen. Zoals gesteld in hoofdstuk 3 worden verschillende typen methoden onderscheiden. Bijvoorbeeld methoden voor het modelleren, methoden voor het beheersen en methoden voor het doorvoeren van leer- en veranderingsprocessen in organisaties. Ook middelenkwaliteit zou, evenals dat voor processen en prodokten het; geval is, uitgedrukt moeten kunnen worden in bepaalde eigenschappen. In literatuur en 1praktijk bestaan hierover uiteenlopende opvattingen. Enerzijds worden middelen beschouwd in relatie tot het ontwikkelwerk waarin ze worden toegepast; anderzijds als op zichzelf staande prodokten (van ander ontwikkelwerk). In de laatste opvatting wordt kwaliteit van methoden bijvoorbeeld ·uitgedrukt in produktkwaliteitseigenschappen als volledigheid, nauwkeurigheid, consistentie etcetera. Dit soort produkteigenschappen is in het afgelopen decennium vaak onderwerp geweest van discussie, zowel in literatuur als praktijk, zie onder andere (Olie et al 1988). Centraal staat dan het beoordelen en onderling vergelijkeJ;l. van methoden. Resultaten van dergelijke analyses bevatten onder meer opsommingen van 'interne' verschilpunten van methoden; bijvoorbeeld qua te modelleren structurele aspecten (c.q. processen, gegevens, gedrag), of qua te hanteren complexiteitsreductievoorschriften (c.q. topdown, bottom-up, centre-out) etc. Belangrijke beperking van dit onderzoek is dat kwaliteit van methoden niet wordt afgemeten aan hun meerwaarde (bijvoorbeeld effectiviteitsverhoging, produktiviteitsstijging) voor het ontwikkelwerk.

In dit boek gaan we uit van een andere opvatting, namelijk dat middelenkwaliteit niet los kan worden gezien van het ontwikkelproces waarin middelen worden ingezet of worden toegepast (Fenton 1991). Dit betekent dat eigenschappen van personele middelen zoals kennis, ervaring en intelligentie alleen betekenis hebben in relatie tot een bepaald soort ontwikkelproces. Bijvoorbeeld verschillen eigenschappen zoals kennis en ervaring die is vereist voor het maken van een bedrijfsmodel sterk met de benodigde kennis en ervaring voor het ontwerpen van programmatuur. Vooralsnog zijn slechts enkele. middeleneigenschappen (summier) beschreven (Fenton 1991). Daarom richten we ons voor wat betreft de kwaliteit van middelen eerst op een beschrijving van middelen en wat ermee afgedekt kan worden in het ontwikkelwerk. Middelenkwaliteit kan pas 'bestaan' wanneer duidelijk is voor welke processen zij kunnen worden ingezet. In het vervolg van dit hoofdstuk bespreken we personele middelen en methoden voor de ontwikkelactiviteiten binnen elk van de ontwikkelaspecten modelleren, beheersen, en leren en veranderen. We beschrijven beperkingen van de huidige middelen door te differentiëren naar het te ontwikkelen type produkt (qua produktscope, -toestanden en -uniekheid).

94

Hoofdstuk 6

6.3 Proces- en middelenkwaliteit vanuit het oogpunt van modelleren 6.3.1 Proceskwaliteit vanuit het oogpunt van modelleren Modelleren, zoals beschreven in hoofdstuk 3 van dit boek, dient beschouwd te worden als de operationele procesvoering in het ontwikkelwerk. Voor proceskwaliteit vanuit het oogpunt van modelleren wordt uitgegaan van de volgende omschrijving: kwaliteit van modelleerprocessen betekent dat het modelleerwerk voldoet aan de eisen herhaalbaarheid en defmieerbaarheid Een herhaalbaar proces beschrijven we hier in analogie met Humphrey (1989) als een proces dat stabiel is. Dejinieerbaarheid van processen gaat een stap verder. Defmieerbaarheid houdt in dat een proces nauwkeurig kan worden omschreven in termen van doel van het proces, volgorde van de verschillende activiteiten, toe te passen modelleerprincipes etcetera. Om te komen tot een herhaalbaar en defmieerbaar proces dient duidelijk te zijn wat onder modelleren kan worden verstaan. Vervolgens kunnen voorschriften worden geformuleerd om proceskwaliteit te bewerkstelligen. In het navolgende omschrijven we verschillen in modelleerprocessen aan de hand van de verschillende typen produkten die qua scope, toestanden en uniekheid kunnen worden onderscheiden. Aansluitend geven we telkens aan welk soort voorschriften dienen te worden geformuleerd om te komen tot een herhaalbaar en defmieerbaar proces. Produkten met een beperkte scope (bijvoorbeeld code) kunnen worden gemodelleerd vanuit een technisch specialisme. Uitgangspunt is dat functionele en kwaliteitsspecificaties bekend zijn. Kenmerkend voor dit ontwikkelwerk is dat ontwerpbeslissingen worden genomen door ontwerpers en dat met name technische en fysieke beperkingen van invloed zijn op het realiseren van specificaties. Bij het modelleren van produkten met een ruime scope (bijvoorbeeld informatiesysteem) staat de context van de te ontwikkelen informatiesystemen centraal. De behoeften van organisaties en afnemers zijn uitgangspunten voor het modelleerwerk. De belangrijkste (ontwerp )beslissingen worden genomen door afnemers en vinden plaats in de eerste fasen van het ontwikkelwerk. Organisatorische beperkingen bepalen hier met name de oplossingsrichting.

Voorschriften om te komen tot een herhaalbaar en defmieerbaar modelleerproces verschillen met de scope van het te ontwikkelen produkt Bij een beperkte scope betreft het bijvoorbeeld voorschriften voor systeemtechnische structurering zoals bijvoorbeeld voorschriften voor gestructureerd programmeren en voorschriften voor het normaliseren van datamodellen. Bij een brede scope gaat het om voorschriften met betrekking tot het modelleren van bedriffsstructuren en het verrichten van veranderingsanalyses. Wanneer ontwikkelaars slechts verantwoordelijk zijn voor (een beperkt aantal) toestanden van een produkt vóór aflevering zijn zij voornamelijk gericht op het maken van vertaalsla95

Proces- en middelenkwaliteit gen van functionele en kwaliteitseisen naar produktkenmerken binnen afgesproken tijd en budget. Ontwikkelaars dragen geen verantwoordelijkheid voor het beheer en het gebruik van een infonnatiesysteem in de organisatie. In deze situatie zullen kwaliteitseisen met betrekking tot invoering, onderhoud en uitbreiding minder relevant zijn voor ontwikkelaars. Bij het modelleren van toestanden van een produkt inclusief onderhoud ~n transitie geldt als doel dat een produkt blijft voorzien in behoeften van de afnemer nadat het produkt is ingevoerd. Dit houdt in dat andere behoeften en wensen van afnemers gespecificeerd moeten worden; bijvoorbeeld met het oog op onderhoud en uitbreiding of transitie van een produkt. Daarnaast dienen wensen en eisen van afnemers met betrekking ,tot bijvoorbeeld invoeren en interen geïdentificeerd te worden. · Afhankelijk van de toestanden van een produkt waarvoor men als ontwikkelaar verantwoordelijkheden heeft zijn verschillende voonchrijten nodig voor het vertalen van produkteisen naar -kenmerken. In geval produkttoestanden als invoering, onderhbud en transitie onder de verantwoordelijkheden vallen van ontwikkelaars zijn meer, met name organisatiegeoriënteerde, voorschriften noodzakelijk dan wanneer het modelleerwerk betrekking heeft op alleen produkttoestanden vóór aflevering (c.q. analyse, ontwerp, constructie).

In de situatie waarin specifieke (unieke) produkten worden ontwikkeld heeft het modelleerwerk veelal een experimenteel karakter. Alleen algemene (generieke) standaards voor het ontwikkelwerk zijn van toepassing. Voorbeelden of referentiekaders van reeds ontwikkelde produkten zijn veelal slechts in beperkte mate van toepassing. Bij de ontwikkeling van standaardprodukten richten ontwikkelaars zich zoveel mogelijk op standaardisatie en modularisatie van (deel)produkten. Fysiek hergebruik van eerder gedaan werk (bijvoorbeeld standaardmodules) speelt een belangrijke rol. Afhankelijk van de mate van uniekheid van een te ontwikkelen produkt verschillen de

voorschriften voor het gebruik van standaards en het hergebruiken van eerder gedaan werk. Het modelleren van een uniek produkt is over het algemeen een niet gedefinieerd proces. Voorschriften (standaards) voor de aanpak en de beheersing van de kwaliteit van het proces zijn zeer generiek van aard. Bij de ontwikkeling van standaardprodukten wordt zoveel mogelijk gestreefd naar een modulaire opbouw van het produkt Voorschriften voor de beheersing van het ontwikkelproces en de standaardisatie van produktcomponenten zijn veelal meer specifiek dan de voorschriften die worden gehanteerd bij het modelleren van unieke produkten. Samenvatting We vatten kort de verschillende voorschriften samen die nodig zijn om proceskwaliteit binnen het modelleren te bewerkstelligen. In dit hoofdstuk is als uitgangspunt genomen dat kwaliteit van het modelleren kan worden uitgedrukt in de proceseigenschappen herhaalbaarheid en defmieerbaarheid. Voorschriften om te komen tot een herhaalbaar en definieerbaar modelleerproces verschillen afhankelijk van de produktscope, de -toestanden en de -uniekheid van het te ontwikkelen produkt Voorbeelden van verschilpunten ~ijn:

96

Hoofdstuk 6 met betrekking tot de produktscope: voorschriften voor het modelleren van technische structuren versus organisatiestructuren; met betrekking tot de produkttoestanden: voorschriften voor het vertalen van een beperkte set (technische) kwaliteitseisen versus voorschriften voor het vertalen van de meest uitgebreide set (organisatorische) kwaliteitseisen; met betrekking tot de uniekheid van een produkt: het vrijwel ontbreken van voorschriften voor het hanteren van ontwerpstandaards versus het sterk op standaards gebaseerde modelleren van 'standaard' -produkten. In onderstaande tabel wordt nogmaals een overzicht gegeven van de karakteristieken van modelleerprocessen zoals die verschillen met het type produkt dat wordt ontwikkeld, zie tabel 6.1.

PRODUKT Produktscope PROCES Modelleren

(van code naar informatie) (modelleerobject) systeemtechnische structuren

versus bedrijfsstructuren

Produktuniekheid Produkttoestanden (van project via onder- (van uniek naar 'standaard') houd naar transitie) (uitgangspunt) ( modelleerproces) generieke voorschrifvertalen van beperkt aantal technische eisen ten als randvoorwaarversus den versus vertalen van diverse organisatorische eisen specifieke standaards als randvoorwaarden

Tabel 6.1: Karakteristieken van modelleren

6.3.2 Kwaliteit van middelen voor bet modeDeren In deze paragraaf bespreken we middelen voor het modelleren en wat zij afdekken in het modelleerwerk. Zoals gesteld is middelenkwaliteit in dit hoofdstuk afhankelijk van de mate waarin middelen kunnen worden toegepast in het ontwikkelwerk. In (NGI 1993) worden verschillende deelgebieden van het ontwikkelwerk -onderscheiden; te weten de deelgebieden systeemontwikkeling, ondersteuning, verwerking en systeemgebruik. De deelgebieden systeemontwikkeling en ondersteuning zijn relevant voor het modelleerwerk. Binnen het deelgebied systeemontwikkeling wordt onderscheid gemaakt tussen de functies projectleider, informatie-analist, systeemontwerper en applicatie-programmeur. Met uitzondering van de eerste functie zijn deze functies van toepassing op het modelleren. Gesteld wordt in het NOl-rapport dat genoemde functies zowel van toepassing zijn op de 97

Proces- en middelenkwaliteit tot stand koming (lees: analyse en ontwerp) als de in stand houding (lees: het onderhouden) van informatiesystemen. De functie van projectleider is gericht op beheersactiviteiten. We komen daarop terug in de volgende paragraaf. Het deelgebied ondersteuning beschrijft verschillende adviserende functies met betrekking tot het modelleren. Enerzijds betreft het functies aan de 'ontwerperszijde' zoals adviseur methoden en technieken en ontwerper architectuur van de technische infrastructuur. Anderzijds worden enkele functies genoemd die gericht zijn op de 'gebruikerszijde' zoals adviseur informatievoorziening, adviseur persoonlijk computergebruik en begeleider persoonlijk computergebruik. Tegen de achtergrond van het onderscheid tussen verschillende soorten modelleerwerk (qua scope van het produkt, de toestanden die een produkt doorloopt, en de mate van uniekheid van een produkt) kunnen de volgende beperkingen in deze opsomming van functies worden genoemd. Op de eerste plaats wordt er in de modelleerfuncties niet gedifferentieerd naar de breedte van de produktscope. Dit houdt bijvoorbeeld in dat de functie informatie-analist zowel van toepassing is op het modelleren van produkten met een zeer ruime scope (bijvoorbeeld bedrijfsmodellering) als op produkten met een zeer beperkte scope (bijvoorbeeld toepassing van furmele talen). Op de tweede plaats worden modelleerfuncties alleen gedifferentieerd naar enkele te modelleren produkttoestanden (c.q. definitie van eisen, analyse, ontwerp, programmeren). Zonder verdere toelichting wordt gesteld dat genoemde functies ook betrekking hebben op onderhoudsactiviteiten. Daarnaast worden enkele onderstenende functies beschreven. Specifieke functies voor het bewerkstelligen van transities van informatiesystem~n (het overgaan van informatiesystemen in andere generaties) worden niet expliciet genoemd. Op de derde plaats wordt geen onderscheid gemaakt tussen analisten en ontwerpers die (nieuwe) unieke produkten ontwerpen en analisten en ontwerpers die in het ontwikkelwerk sterk zijn gebonden aan eerder gedaan werk (bijvoorbeeld gestandaardiseerde componenten).

ModeUeennethoden vormen de meest omvangrijke categorie van methode,n voor het ontwikkelwerk. Bekende voorbeelden zijn de methoden ISAC (Information Systems work and analysis of Changes) (Lundeberg et al 1982), NIAM (Nijssen Information Aanalyse Methode) (Wintraecken 1987), Information Engineering Methodology (Martin 1986), Modem Structured Analysis (Yourdon 1989) etcetera. Centraal in modelleermethoden staat het specificeren en realiseren van functionele eisen ofwel de 'structurele' aspecten (lees: processen, gegevens en gedrag) van informatiesystemen, zie hoofdstuk 3. In de informatiesystemenwereld wordt in toenemende mate belang gehecht aan het gebruik van formele methoden (Basili en Musa 1991). Formele methoden maken gebruik van een specificatietaal die is gebaseerd op wiskundige pricipes (logica). Een van de voordelen is dat specificaties nauwkeuriger en consistenter kunnen worden beschreven. Voorbeelden van formele methoden zijn Z, VDM en Exspect (zie onder andere (Aerts et al 1991)). Formele methoden zijn niet in alle ontwikkelsituaties efficU!nt en effectief toepasbaar (Bergstra et al 98

Hoofdstuk 6

1989), onder meer als gevolg van de geringe leesbaarheid en inzichtelijkheid van formele specificaties voor gebruikers. Tegen de achtergrond van het onderscheid in produkttype, qua scope, toestanden en uniekheid kunnen de volgende beperkingen worden genoemd. Modelleermethoden kunnen in tegenstelling tot de personele functies op het gebied van modelleren wel worden gedifferentiëerd naar de breedte van de produktscope. Bijvoorbeeld een methode als ISAC richt zich in eerste instantie (in de veranderingsanalyse) op het belang ofwel de waarde van informatie(systemen) voor een organisatie. Formele methoden als ExSpect richten zich daarentegen met name op het specificeren van software en het genereren van code. Met betrekking tot de produkttoestanden die worden doorlopen beperken modelleermethoden zich vrijwel allen tot het modelleren van de produkttoestanden van een produkt vóór oplevering, met andere woorden de tussen- en eindprodukten van projectwerk. Bijvoorbeeld claimt ISAC alle produkttoestanden binnen een project af te dekken; formele methoden als Z, VDM en Exspect beperken zich tot met name het functioneel en technisch ontwerp. Geen enkele modelleermethode richt zich op het modelleren van produkttoestanden ná oplevering (c.q. de produkttoestanden invoering, onderhoud en transitie). Modelleermethoden vertonen geen differentiatie in relatie tot de mate van uniekheid van een produkt. Modelleermethoden huldigen wat dit betreft de 'groene weide' aanpak en richten zich op nieuwbouw. Vooralsnog ontbreken methoden die zich richten op hergebruik, enerzijds met betrekking tot het op basis van componenten ontwikkelen van bijvoorbeeld standaardpakketten en anderzijds met betrekking tot het ontwerpen van generieke componenten. Samenvatting De beperkingen van personele middelen en methoden worden duidelijk wanneer we de toepasbaarheid ervan per type te modelleren produkt beschrijven. Bijvoorbeeld blijkt dan dat personele functies (NGI 1993) alleen gedifferentieerd zijn naar de toestanden die door een produkt worden doorlopen tot aan oplevering van dat produkt. Functies worden niet gedifferentieerd naar de breedte van de scope van een produkt dat wordt ontwikkeld of de mate van uniekheid van een te ontwikkelen produkt. Ook blijkt dat methoden voor het modelleren zich met name richten op nieuwbouw en op het modelleertraject tot aan de oplevering van een produkt. Modelleermethoden houden vooralsnog geen rekening met de mate uniekheid van een te ontwikkelen produkt.

6.4 Proces- en middelenkwaliteit vanuit het oogpunt van beheersen 6.4.1 Proceskwaliteit vanuit het oogpunt van beheersen Beheersen, zoals beschreven in hoofdstuk 3 van dit boek heeft onder andere betrekking op planning en controle van het primaire proces van systeemontwikkeling, c.q. het modelleren. Proceskwaliteit van het beheersen wordt als volgt omschreven:

99

Proces- en middelenkwaüteit kwaliteit van beheersprocessen betekent dat deze processen voldoen aan de eisen van controleerbaarheid en bestuurbaarbaarheid Met Humphrey (1989) en Fenton (1991) stellen we dat controleerbaarheid en bestuurbaarheid dienen te worden bewerkstelligd door onder andere voorschriften op te stellen voor het registreren (en analyseren) van ontwikkelgegevens. In het navolgende beschrijven we dat evenals het modelleren ook het beheersen verschillen vertoont afhankelijk van het type te ontwikkelen produkt. In samenhang daarmee varleeren voorschriften om te komen tot een controleerbaar en bestuurbaar proces. Evenals in voorgaande paragraaf beschrijven we telkens twee uiterste vormen van beheersing met betrekking tot de scope, de toestanden en de uniekheid van een produkt. Vanuit het oogpunt van het beheersen van de ontwikkeling van een produkt met een beperkte scope (bijvoorbeeld beperkt tot code) is de interne complexiteit van het ontwikkelwerk de bepalende factor voor de controleerbaarheid en de bestuurbaarheid. Bij een beperkte scope wordt de complexiteit bepaald door (het aantal) ontwerptechnische factoren. Het beheersen van het ontwikkelwerk van een produkt met een brede scope heeft betrekking op het beheersen van factoren van verschillende aard. Naast technische factoren wordt complexiteit bepaald door organisatorische en sociale factoren. · Een van de voorwaarden om het ontwikkelwerk controleerbaar en bestuurbaar te maken is de registratie van proces- en produktgegevens. Afhankelijk van de scope van het produkt verschillen voorschriften daarvoor. Bijvoorbeeld gaat het bij een beperkte scope om voorschriften voor het registreren van constructietechnische beslissingen in ontwerpdocumenten. Bij een ruime scope gaat het om voorschriften voor het registreren v~ behoeften en wensen van afnemers in produktdocumenten. Door beide vormen van registreren worden beslissingen in het ontwikkelwerk traceerbaar of controleerbaar). Het beheersen van ontwikkelwerk dat zich beperkt tot enkele produkttoestanden v66r het bereiken van de toestand van invoering (bijvoorbeeld analyse, ontwerp, constructie) wordt aangeduid met projectbeheersing (van Genochten 1991). De verantwoordelijkheden van de ontwikkelaars reiken niet verder dan het tegen geld en kosten afleveren van een produkt. De beheerssituatie waarin het gaat om produkttoestanden tot en met invoering, onderhoud en transitie wordt aangeduid met produktbeheersing (van Genochten 1991). De ontwikkelaar blijft na invoering van het produkt in de organisatie verantwoordelijk. Het produkt dient te worden geëxploiteerd en beheerd. Communicatie met de afnemers (opdrachtgevers, gebruikers, beheerders) is van cruciaal belang. ·

Afhankelijk van de produkttoestanden waarvoor men verantwoordelijk is !dienen met het oog op controleerbaarheid en bestuurbaarheid verschillende gegevens te worden verzameld en geanalyseerd.

100

Hoofdstuk6 Bij projectbeheersing gaat het om voonelui/ten voor het registreren van ontwikkelgegevens (tussenresultaten of mijlpaalprodukten) voor het bijsturen en controleren van de projectvoortgang. Bij produktbeheersing gaat het om voorschriften voor het registreren van ervaringsgegevens van een organisatie met een produkt; bijvoorbeeld met het oog op het aanpassen van onderhoud, service en transitie. Bij de beheersing van de ontwikkeling van een specifiek (uniek) produkt gaat het om de beheersing van onder meer exploratief werk. Deze situatie wordt onder andere gekenmerkt door het ontbreken van volledig inzicht in alle proces- en produktfactoren. Dit betekent dat het eindresultaat niet precies bekend is evenals de weg waarlangs het eindresultaat bereikt dient te worden. Samenwerking vindt plaats op basis van afspraken tussen specialisten; formele (gestandaardiseerde) coördinatie tussen ontwikkelaars is nauwelijks mogelijk. Bij de beheersing van de ontwikkeling van een stantloard produkt gaat het om de beheersing van de ontwikkeling van volledig gespecificeerde produkten binnen een beperkt aantal produktfamilles. Standaardisatie van proces- en produktcomponenten is ver doorgevoerd. Allocatie van middelen (personeel en tools) en de coördinatie van de communicatie is sterk gestructureerd. Voor de beheersing van de ontwikkeling van specifieke (unieke) produkten kunnen voor· schriften worden opgesteld voor te behalen resultaten versus inspanningen (tijd en geld). Daarentegen kunnen voor de beheersing van standaardproduktontwikkeling voorschriften worden opgesteld voor het gedetailleerd en gestandaardiseerd vastleggen van ontwikkelgegevens (bijvoorbeeld standaard produktmodules). Samenvatting Proceskwaliteit met betrekking tot beheersen wordt uitgedrukt in de proceseigenschappen

controleerbaarheid en bestuurbaarheid. Controleerbaarheid en bestuurbaarheid staan of vallen met het registreren van ontwikkelgegevens. Om deze proceseigenschappen te bewerkstelligen zijn afhankelijk van het type produkt verschillende soorten voorschriften noodzakelijk: naarmate de scope van een produkt breder wordt nemen naast voorschriften voor het registreren van technische ontwerpbeslissingen voorschriften voor het analyseren van bedrijfsbehoeften in belang toe (in verband met de traceerbaarbeid van bedrijfsinformatiebehoeften naar ontwerpbeslissingen en het verantwoord kunnen bijsturen); naarmate men verantwoordelijk is voor meerdere toestanden van een produkt nemen naast voorschriften voor de registratie van projectvoortgangsgegevens voorschriften voor registratie van ervaringsgegevens van afnemers met bestaande produkten in belang toe (ten behoeve van onderhoud en transitie van een produkt);

101

Proces- en middelenkwaliteit naannate een te ontwikkelen produkt een grotere mate van uniekheid heeft nemen naast voorschriften voor het registreren van inspanning/resultaat-verhoudingen voorschriften voor het registreren van gegevens met betrekking tot beheer- en exploitatie van generieke componenten in belang toe. We vatten nogmaals de karakteristieken van het beheersen samen in tabel 6.2. PRODUKT PROCES

Produktscope (van code naar informatie)

Produkttoestanden Produktuniekheid (van project via onder- (van uniek naar 'standaard') houd naar transitie)

Beheersen

(beheersobject)

(beheers proces)

(uitgangspunt)

met name constructie-technische complexiteit

projectbeheersing

met name inspanning/resultaat

of

of tevens

of tevens

produktbeheersing

generieke componqnten (configuratie/versiebeheer)

bedrijfskundige complexiteit

Tabel 6.2: Karakteristieken van beheersen

6.4.2 Middelen voor beheersen Verschillendefuncties binnen de door (NGI 1993) beschreven deelgebieden hebben betrekking op het beheersen van ontwikkelwerk en het beheer van informatiesystemen. De binnen het NOl-deelgebied ontwikkeling beschreven functie van projectleider heeft betrekking op de beheersing van het ontwikkelwerk. Centraal staat in deze functiebeschrijving het beheersen van tijd en kosten van een project en het coördineren :en leidinggeven aan samenwerkingsverbanden. De functies die worden beschreven binnen de NOl-deelgebieden verwerking en systeemgebruik hebben betrekking op beheer en exploitatie van informatiesystemen. Binnen het deelgebied verwerking hebben zij betrekking op respectievelijk de instandhouding van de gegevensverwerking en het optimaal beheer van apparatuur, programmatuur en datacommunicatiefaciliteiten. Voorbeelden van beheerfuncties zijn respectievelijk systeemprogrammeur, beheerder technische infrastructuur, produktiebegeleider en operateur. Binnen het deelgebied systeemgebruik staat centraal het doelmatig functioneren van de informatievoorziening binnen de gebruikersorganisatie. Voorbeelden van beheerfuncties zijn: coördinator informatievoorziening, applicatiebeheerder en beheerder computerfaciliteiten.

102

Hoofdstuk 6

Beschrijft men deze beheer(s)functies tegen de achtergrond van de soorten prodokten dan geldt een aantal beperkingen.

In de beschrijvingen van de beheerfuncties (op de deelgebieden ontwikkeling, verwerking en gebruik) wordt niet gediffferentieerd naar de produkttoestanden en naar scope van een informatiesysteem (bijvoorbeeld het beheren van informatie'waarde' versus het beheren van gegevens), of naar de mate van uniekheid van een systeem (bijvoorbeeld het beheer van lokale 'stand alone' applicaties versus het beheren van integrale standaardpakketten). De functie van projectleider (deelgebied ontwikkeling) is beperkt tot de toestanden van een systeem tot aan oplevering. Er zijn geen specifieke functies voor het plannen en bewaken van transities, noch voor het beheersen van de ontwikkeling van standaardsoftware. Beheersmethoden ondersteunen het maken van plannen, het controleren en het aanbrengen van wijzigingen binnen het ontwikkelwerk (zie de managementcyclus in hoofdstuk 3). Voorbeelden van beheersmethoden zijn SDM -(System Development Methodology) (Turner et al 1989), en PROOOSTA (Project Documentatie Standaard) (Krooshof et al 1987). In tegenstelling tot methoden voor het modelleren is de klasse van beheersmethoden qua omvang vrij beperkt Beheersmethoden hebben met name betrekking op het faseren en documenteren. Het beheersen van de kosten en met name van de kwaliteit krijgen in bovengenoemde beheersmethoden minder aandacht Tegen de achtergrond van de verschillende type produkten kunnen de volgende beperkingen worden genoemd.

Beheersmethoden geven slechts globale richtlijnen voor het beheersen van de ontwikkeling van een produkt met een brede scope. Beheersmethoden bieden alleen ondersteuning met betrekking tot het doorlopen van produkttoestanden. Produkttoestanden (c.q. tussen- of deelprodukten) van een produkt worden beschreven in mijlpaaldocumenten. Produkttoestanden ná oplevering worden niet of slechts summier beschreven. Recent is door (Looijen 1993) een aparte methode ontwikkeld voor het beheren van informatiesystemen en softwareprodokten ná oplevering. Beheersmethoden geven verder beperkte ondersteuning voor de beheersing van de ontwikkeling op basis van standaardcomponenten. Voor een evenwichtige beheersing van het ontwikkelwerk dienen genoemde beheersmethoden aangevuld te worden met onder andere geschikte methoden voor begroten, zie bijvoorbeeld (Heemstra 1989), en methoden voor kwaliteitsbeheersing. Voor wat betreft dit laatste kan worden uitgegaan van kwaliteitsstandaards voor software-ontwikkeling, bijvoorbeeld (ISO 9000-3 1991) en van methoden voor het verifiëren en valideren van tussen- en deelprodukten. Voorbeelden zijn Structured Walk.througs (Yourdon 1985) en Fagan's Inspectiemethode (Fagan 1986) voor het controleren van specificaties. Samenvatting Functiebeschrijvingen van personele middelen en methoden voor beheer en beheersing van het ontwikkelwerk hebben op een aantal punten beperkingen. Die beperkingen worden duidelijk wanneer deze middelen worden beschreven tegen de achtergrond van de verschillende produktdefinities. 103

Proces- en middelenkwaliteit Op de eerste plaats is slechts één type beheersfunctie beschreven, namelijk die van projectleider. Deze functie is beperkt tot projecunatig werk en wel het afleveren van een produkt tegen afgesproken tijd en geld. Differentiaties in functiebeschrijvingen naar beheersing van complexe versus eenvoudige projecten worden niet gegeven. Dit geldt ook voor differentiaties in beheersing met betrekking tot de uniekheid van h~t te ontwikkelen produkt Wat betreft beheersmethoden geldt dat deze ondersteuning bieden voor faseren en documenteren. Daarbij wordt uitgegaan van een aantal toestanden die door een produkt worden doorlopen. Vrijwel geen rekening wordt gehouden met de verschillen in scope of de mate van uniekheid van een te ontwikkelen produkt.

6.5 Proces- en middelenkwaliteit vanuit het oogpunt van leren en veranderen 6.5.1 Proceskwaliteit vanuit het oogpunt van leren en veranderen Vanuit het oogpunt van leren en veranderen wordt proceskwaliteit als volgt omschreven: kwaliteit van leer- en veranderprocessen betekent dat deze processen voldoen aan de eis verbeterbaarheid Verbeteringen hebben zowel betrekking op de efficiëntie en de effectiviteit van het ontwikkelwerk als op de inhoudelijke verbetering van produkten. Verbeteren houdt meer in dan het onder controle houden of bijsturen. Bij dat laatstgenoemde gaat het om tijdelijk ingrijpen of koerscorrecties op grond van (tussen)resultaten of gebeurtenissen. Er is geen leereffect. Uitgangspunt voor verbeteren is inzicht in bestaande kennis en vaardigheden en eerder gedaan werk (resultaten en werkwijzen). · In het navolgende richten we ons op leren en veranderen met betrekking tot respectievelijk de scope, de toestanden van een produkt en de uniekheid van een produkt. In samenhang daarmee geven we voorbeelden van voorschriften voor verbeterbaarheid. Bij de ontwikkeling van een produkt met een beperkte scope zijn ontwikkelaars infonnatica-technische specialisten. Hun houding ten aanzien van het ontwikkelwerk kan rationeeltechnisch zijn (zie hoofdstuk 3). Leren en veranderen vertaalt zich hier in een toename van kennis en ervaring van personeel. Bij de ontwikkeling van een produkt met brede scope, is bedrijfskundig geschoold personeel noodzakelijk. De houding van dit type ontwikkelaar ten aanzien van het ontwerpen van infonnatiesystemen wordt aangeduid met communicatief/therapeutisch. Leren en veranderen heeft ook hier betrekking op een toename van kennis en ervaring van personeel, zij het van een geheel andere signatuur dan die in voorgaande alinea.

104

Hoofdstuk 6

Voorschriften om te komen tot verbeteringen in het ontwikkelwerk zijn in dit kader voorschriften voor het opleiden en trainen van personeel. Afhankelijk van de scope van een produkt gaat het om de disciplines informatica dan wel bedrijfskunde. Zoals gesteld dragen ontwikkelaars in een ontwikkelsituatie exclusief onderhoud en tran· sitie geen verantwoordelijkheid voor het produkt ná oplevering. Ontwikkelaars zijn georiënteerd op het 'maken' van een produkt. Leren en veranderen heeft betrekking op het optimaliseren van dit soort projectwerk.

In een ontwikkelsituatie waarin verantwoordelijkheden gelden voor de gehele levenscyclus van een produkt (inclusief onderhoud en transitie) dient een produkt geïntegreerd in een organisatie, onderhouden en uitgebreid te kunnen worden. Leren en veranderen heeft hier met name betrekking op het optimaliseren van de inpassing van een produkt in een organisatie.

Voorschriften voor verbeteringen slaan in dit kader enerzijds op periodieke aanpassing aan de 'state of the art' van de technologie (technologie gedreven) en anderzijds op afstemming op de veranderende behoeften van organisaties (organisatiebehoeften gedreven). Evenals onder het punt leren en veranderen met betrekking tot de scope, gelden ook hier specialistische opleidingen en trainingen (hetzij informaticatechnisch, hetzij bedrijfskundig). Bij de ontwikkeling van een specifiek (uniek) produkt is niet op voorhand aan te geven hoe leren en veranderen plaatsvinden. Zoals gesteld is noch het eindprodukt, noch het ontwikkelproces eenduidig en volledig te beschrijven. In de situatie dat stmulaardprodukten worden ontwikkeld is het ontwikkelwerk gebaseerd op eerder gedaan werk. Uitgangspunt voor standaardprodokten is het ontwerpen van generieke componenten. Een centrale plaats in dit ontwikkelwerk wordt ingenomen door configuratie- en versiebeheer van produktfamilies. Werken aan verbetering is bij de ontwikkeling van een specifiek produkt lastiger. Personeel is de cruciale factor. Verbetering kan worden nagestreefd door voorschriften voor het periodiek herzien van allerlei randvoorwaarden van financié5le, ergonomische en sociale aard. Bij de ontwikkeling van standaardprodokten worden verbeteringen nagestreefd in generieke produktstructuren. Voorschriften kunnen betrekking hebben op het verbeteren van exploitatie en beheer van generieke componenten (configuratie- en versiebeheer). Bijvoorbeeld door voor het ontwikkelen van generieke componenten aparte ontwikkelafdelingen op te zetten, los van de ontwikkelaars die klantspecifieke prodokten ontwikkelen. Samenvatting Proceskwaliteit vanuit het oogpunt van leren en veranderen wordt uitgedrukt in termen zoals verbeterbaarheid. Voorschriften om te komen tot een verbeterbaar ontwikkelwerk dienen gebaseerd te zijn op inzicht in bestaande werkwijzen en produkten. Het uitgaan van reeds gedaan werk of bestaande inzichten krijgt daa.tmee een andere dimensie dan alleen 105

Proces- en middelenkwaliteit bijsturen en controleren. Doel is het ontwikkelwerk structureel te verbeteren. Voorschriften om verbeterbaarbeid in het ontwikkelwerk te bewerkstelligen verschillen met het type produkt dat wordt ontwikkeld. Samengevat zijn deze verschilpunten in voorschriften respectievelijk: met betrekking tot de produktscope: voorschriften voor respectievelijk informaticatechnische opleidingen versus voorschriften voor bedrijfskundige opleidingen; met betrekking tot de produkttoestanden waarvoor men verantwoordelijk is: voorscllriften voor het (periodiek) aanpassen van de technologie aan de 'state of the art' versus voorschriften voor het identificeren van veranderende wensen en eisen van organisaties; met betrekking tot de uniekheid van een produkt: voorschriften voor het (periodiek) aanpassen en verbeteren van randvoorwaarden (bijvoorbeeld financieel of ergonomisch) versus voorschriften voor het ontwikkelen en optimaliseren van generieke produktstructuren. We geven een overzicht van de karakteristieken van leren en verandereq in onderstaande tabel. '

PRODUKT Produktscope (van code naar informatie) PROCES Leren/ (object van leren en Veranderen veranderen)

Produkttoestanden (van project via onderhoud naar transitie) (leer- en veranderproces)

Produktuniekheid (van uniek naar 'standaard') (uitgang~punt)

informatica kennis en kunde

technologie gedreven

versus

organisatiebehoeften gedreven

randvoorwaarden (technisch/ ergonomisch)

bedrijfskundige kennis en kunde

versus

versus generieke produktstructuren

Tabel 6.3: Karakteristieken van leren en veranderen

6.5.2 Middelen voor leren en veranderen In (NGI 1993) wordt in enkele functiebeschrfivingen gerefereerd aan het begeleiden van veranderingsprocessen in organisaties. Genoemd kunnen worden de functies van onder andere projectleider, adviseur informatievoorziening en informatie-analist.

106

Hoofdstuk 6

Met betrekking tot leren wordt een overzicht van vaardigheden van ontwikkelaars gegeven. Onderscheid wordt gemaakt tussen cognitieve vaardigheden (onder andere vakkennis), bestuurlijke vaardigheden (onder andere motiveren, besluitvaardigheid, begeleiding), sociale vaardigheden (onder andere werken in teamverband, onderhandelen) en intellectuele vaardigheden (onder andere modelleren, analytisch denken). Tegen de achtergrond van het onderscheid in verschillende soorten produkten kunnen opnieuw beperkingen worden genoemd.

In de functiebeschrijving van informatie-analist wordt geen onderscheid gemaakt tussen informatie-analisten die zich dienen te richten op een bedrijftkundige veranderingsproblematiek of analisten die formele specificaties voor een afgebakend systeem moeten opleveren. Onder meer door (Willmot et al 1990, Hirscheim en Klein 1989) is beschreven dat voor de verschillende analysewedczaamheden sterk uiteenlopende houdingen en kennis en vaardigheden vereist zijn. 'liJ kan onderscheid worden gemaakt tussen de 'conventionele' opstelling (ofwel de ontwikkelaar bepaalt wat de juiste informatie(technische)-oplossing is), de 'progressieve opstelling' (de ontwikkelaar zoekt samen met afnemers naar nieuwe mogelijkheden), en de 'sociaalverantwoordeliJke opstelling' (de ontwikkelaar streeft samen met afnemers naar verbetering voor een organisatie). In (NOl 1993) ontbreken functies voor het verbeteren van het ontwikkelwerk, bijvoorbeeld functies voor het organiseren en inrichten van hergebruik of functies voor het organiseren van speciale samenwerkingsverbanden gericht op kwaliteitverbetering (bijvoorbeeld kwaliteitscirkels). In de literatuur worden enkele methoden beschreven die zijn gericht op het doorvoeren van veranderingsprocessen in organisaties. Deze methoden ondersteunen met name het beschrijven van de context van een informatieprobleem. Bijvoorbeeld wordt als uitgangspunt genomen de sociale en politieke context van een probleemsituatie. Enkele representanten van methoden voor leren en veranderen zijn de metboden Ethics (Mumford 1983), Multiview (Avison en Wood-Harper 1990) en Metaplan (Schnelle en Stolz 1977). De methoden Ethics en Multiview vertonen met name in de latere fasen van het ontwikkelwerk overeenkomsten met methoden voor het modelleren. Metaplan is een methode die alleen gericht is op het structureren van de communicatie tussen ontwikkelaars en andere betrokkenen. Methoden voor leren en veranderen richten zich met name op de meest ruime produktscope; namelijk de scope waar het beschrijven van de waarde van informatie voor een organisatie centraal staat. Met name voor de eerste fasen van het ontwikkelwerk worden richtlijnen, voorschriften en (schema)technieken aangereikt voor het beschrijven van de probleemcontext (Ethics en Multiview). 'liJ schrijft Multiview het gebruik voor van aparte symbolen bij het modelleren van sociale en politieke aspecten van een informatieprobleem (bijvoorbeeld belangen, interesses, machtsverhoudingen etcetera). De 'rich pictures' die daarmee ontstaan zijn bedoeld als discussiehulpmiddel om te komen tot een eerste ont-

107

Proces- en middelenkwaliteit werp. Door Metaplan wordt voorgeschreven op welke wijze de communicatie tussen betrokkenen dient te worden gestructureerd. Voor de dimensies produkttoestand en produktuniciteit .bieden de sociotechnisChe methoden evenals de methoden voor het modelleren beperkte ondersteuning. Samenvatting Slechts in enkele functiebeschrijvingen in (NGI 1993) wordt gerefereerd aan leren en veranderen. Met name functies gericht op het verbeteren van het ontwikkelwerk ontbreken; bijvoorbeeld voor het onderzoeken en inschatten van nieuwe mogelijkheden van informatietechnologie, functies met betrekking tot kwaliteitsverbetering en functies met betrekking tot hergebruik. Et wordt niet gedifferentieerd naar soorten veranderingsprocessen; bijvoorbeeld integrale organisatieveranderingen versus beperkte organisatieveranderingen bij de oplevering van locale maatwerkappücaties. Gesteld kan worden dat methoden voor leren en veranderen extra ondersteuning (ten opzichte van modelleermethoden) bieden met betrekking tot het modelleren van een produkt met een brede scope.

6.6 Samenvatting en conclusies Over het verrichten van metingen aan processen en middelen om . de kwaüteit ervan te kunnen bepalen bestaat in literatuur en praktijk vooralsnog weinig eendUidigheid (Fenton 1991). Uitgaande van de stelling 'weten voordat kan worden gemeten' is getracht in dit hoofdstuk een zo goed mogelijke beschrijving te geven van het ontwïlckelwerk: en de middelen die daarin worden toegepast. Uitgangspunten daarbij waren respectievelijk de soorten ontwikkelprocessen modelleren, beheersen, leren en veranderen en de verschillende produktdefinities (scope, toestanden en uniekheid van een produkt). Met betrekking tot proceskwaliteit zijn op grond van het groeimodel van (Humphrey 1989, Fenton 1991) in dit hoofdstuk vijf generieke proceseigenschappen gehartteerd, te weten herhaalbaarheid, defmieerbaarheid, controleerbaarheid, bestuurbaarheid en verbeterbaarheid. Vanuit het oogpunt van het modelleren zijn met name van belang de proceseigenschappen herhaalbaarheid en definieerbaarheid. Vanuit het oogpunt van beheersen zijn van belang de proceseigenschappen controleerbaarheid en bestuurbaarheid. Een proceseigenschap die vanuit het oogpunt van leren en veranderen moet worden nagestreefd is de eigenschap verbeterbaarheid. Om proceskwaliteit, c.q. genoemde proceseigenschappen, te bewerkstelligen zijn voorbeelden van voorschriften beschreven. Ten aanzien van de kwaliteit van middelen het volgende: door bij het beschrijven van personele middelen en methoden uit te gaan van de drie produktdimensies produktscope, produkttoestanden en uniekheid van een produkt wordt duidelijk in welke mate ontwikkelprocessen worden afgedekt en wat de beperkingen zijn van de huidige middelen.

108

Hoofdstuk 6 Zoals duidelijk is geworden in dit hoofdstuk is op het gebied van proces- en middelenkwaliteit eerst nog veel werk te doen voor wat betreft het definilSren en uitwerken van kwaliteitseigenschappen. Gezien de literatuur over softwarekwaliteit is dit niet verwonderlijk. Ter vergelijking: de eerste publicaties over kwaliteitseigenschappen van softwareprodokten verschenen aan het eind van de jaren '70, onder andere (Boehm, Cavano en McCall), de eerste publicaties over kwaliteitseigenschappen van processen en middelen verschenen pas eind jaren '80, zie onder andere (Humphrey 1989, Bush en Fenton 1990).

109

7

Naar een methode voor het specificeren van kwaliteitseisen

7.1 Inleiding In dit hoofdstuk gaan we nader in op het omgaan met kwaliteitseisen. In literatuur en praktijk is tot op heden de aandacht voor kwaliteitseisen beperkt gebleven tot opsommingen en omschrijvingen. Dat is uitvoerig aan de orde geweest in hoofdstuk 4. In de benaderingswijzen, methoden en technieken voor het specificeren van de eisen voor een informatiesysteem staat centraal het modelleren van functionele aspecten (respectievelijk: data-, proces- en gedragsaspecten) van informatiesystemen. Hoewel kwaliteitseisen veelal als een aparte klasse van eisen worden onderscheiden ontbreekt ondersteuning voor het specificeren van kwaliteitseisen vrijwel geheel (Bemelmans 1991). Hoofdstuk 5 heeft laten zien dat door een karakterisering van een informatiesysteem op drie dimensies, van de scope, de toestanden en de uniekheid van een produkt, indicaties worden verkregen van de relevantie van kwaliteitseisen voor een systeem. Voor een beperkt aantal kwaliteitseisen geldt dat de relevantie voor een systeem invariant is binnen de drie dimensies van een produkt. Gesteld is in hoofdstuk 5 dat aanvullende informatie over een produkt (lees: een informatiesysteem of softwareprodukt) nodig is om te kunnen bepalen of die kwaliteitseisen relevant zijn. In dit hoofdstuk wordt een methode beschreven voor het specificeren van kwaliteitseisen. Daarbij wordt voortgebouwd op de resultaten van hoofdstuk 5.

In paragraaf 7.2 wordt eerst ingegaan op wat in literatuur en praktijk bekend is omtrent werkwijzen voor het specificeren en realiseren van kwaliteitseisen. In paragraaf 7.3 wordt kort ingegaan op wat kan worden geleerd van benaderingswijzen voor het specificeren van informatiebehoeften. Dit resulteert in een beschrijving van een benaderingswijze voor de specificatie van kwaliteitseisen. De paragrafen 7.4 en 7.5 beschrijven vervolgens een uitwerking van deze benaderingswijze naar een methode. Bij de ontwikkeling van een checklijst voor de bepaling van de karakteristieken van een bedrijfssituatie wordt gebruik gemaakt van het PBI-model (waarbij P staat voor proces, B voor besturing van dat proces en I voor informatie). Doel is om op grond van de bedrijfskarakteristieken, van zowel P als B, te bepalen welk type informatiesysteem nodig is en welke de relevante kwaliteitseisen zijn. Paragraaf 7.6 sluit dit hoofdstuk af met een samenvatting en conclusies.

7.2 Omgaan met kwaliteitseisen Hoofdstuk 5 heeft laten zien dat produktkarakteristieken een belangrijk uitgangspunt zijn voor het specificeren van kwaliteitseisen. Kwaliteitseisen vormen op hun beurt het uitgangspunt om produkteigenschappen in een produkt in te bouwen (zie onder andere hoofdstuk 4). Produktkarakteristieken, kwaliteitseisen en produkteigenschappen hebben betrekking op het Wat van het omgaan met kwaliteitseisen. In dit hoofdstuk gaan we nader in op het Hoe van het omgaan met kwaliteitseisen en de beperkingen daarvan. Vervolgens wordt een methode ontwikkeld voor het specificeren van kwaliteitseisen.

111

Naar een methode voor het specificeren van kwaliteitseisen

7.2.1 Eérst specificeren dan realiseren Met betrekking tot het omgaan met kwaliteitseisen onderkennen we in dit boek twee trajecten, zie figuur 7 .1.

AFNEMER

.,..lll(~o------....,..,_~

realiseren

specificeren kwaliteitsbehoeften

kwaliteitseisen

MAKER

produkteigenschappen

Figuur 7.1: Specificeren en realiseren van kwaliteitseisen Respectievelijk betreft het een traject waarop activiteiten dienen te worden verricht om kwaliteitseisen af te leiden uit kwaliteitsbehoeften (het specificatietraject) en een traject waarop activiteiten worden verricht om kwaliteitseisen te realiseren (het realisatietraject). We merken op dat het uiteraard niet de bedoeling is dat de trajecten van specificeren en van realiseren strikt gescheiden van elkaar worden beschouwd. Terugkoppeling tussen de twee trajecten doen zich telkens voor wanneer afwegingen worden gemaakt tussen enerzijds kwaliteitsbehoeften en te specificeren kwaliteitseisen en anderzijds de gespecificeerde kwaliteitseisen en te nemen maatregelen en de tijd en de kosten die daarmee gemoeid zijn. Voor het realisatietraject zijn in literatuur en praktijk reeds verschillende benaderingswijzen, methoden en technieken ontwikkeld. Internationaal gezien is de Goal-Question-Metric benadering volgens (Basili en Rombach 1988) het meest bekend. In Nederland is een van de meest recente publicaties die van (Serc-Quint 1992). We gaan daar in de navolgende paragraaf nader op in. Op het specificatietraject zijn concrete handreikingen voor benaderingswijzen, methoden en technieken zeer schaars. Zoals beschreven in hoofdstuk 5 dient voor het specificeren van kwaliteitseisen op grond van kwaliteitsbehoeften gebruik te worden gemaakt van de drie dimensies van respectievelijk de scope, de toestanden en de uniekheid van een informatiesysteem. In deze paragraaf bespreken we kort een werkwijze op het realisatietraject Vervolgens bespreken we de beperkingen van het ontbreken van een werkwijze op het specificatietraject

112

Hoofdstuk 7

7.2.2 Realiseren van kwaliteitseisen De huidige wijze van omgaan met kwaliteitseisen wordt beschreven aan de hand van de navolgende figuur 7.2 (Delen, Kouwenhoven en Rijsenbrij 1991). vergelijken kwallteltsbehoefte

bepalen

Figuur 7.2: De kringloop van produktkwaliteit (Delen, Kouwenhoven en Rijsenbrij 1991) Deze 'kwaliteits' -kringloop kent drie typen objecten. Achtereenvolgens zijn deze getiteld: 'kwaliteitseisen', 'maatregelen' en 'eigenschappen'. Zoals eerder gesteld in dit boek (hoofdstuk 2 en hoofdstuk 4) worden onder kwaliteitseisen verstaan de niet-functionele specificaties waaraan een infonnatiesysteem moet voldoen. Maatregelen zijn handelingen die een maker moet verrichten om kwaliteitseisen in een infonnatiesysteem te bewerkstelligen. Eigenschappen zijn 'kwaliteits' -kenmerken van een informatiesysteem. De bedoeling is dat telkens na elke fase wordt geverifieerd of ook daadwerkelijk is voldaan aan wat in een voorgaande stap werd besloten. Een belangrijk probleem en reeds verschillende malen in literatuur en praktijk gesignaleerd probleem bij de realisatie van kwaliteitseisen is de onderlinge beïnvloeding van kwaliteitseisen. Dit houdt in dat het nemen van maatregelen om een bepaalde kwaliteitseis te realiseren tot gevolg heeft dat aan een andere kwaliteitseis niet of in mindere mate kan worden voldaan. Het in hoofdstuk 3 beschreven ontwikkelaspect balanceren is hierop van toepassing. De onderlinge beïnvloeding van kwaliteitseisen wordt in onderstaande figuur geffiustreerd met het zogeheten 'duivelsvierkant', zie figuur 7.3. De figuur geeft aan dat het nemen van maatregelen om een bepaalde kwaliteitseis in een der hoekpunten te realiseren ten koste kan gaan van de realisatie van andere eisen in de andere hoekpunten. In feite gaat het bij systeemontwikkeling niet om een vierhoek, maar om een multi-dimensionale ontwerpruimte waarbinnen afwegingen moeten worden gemaakt tussen verschillende soorten eisen, te weten kwaliteitseisen, functionele eisen en beheerseisen zoals tijd en budget (zie hoofdstuk 3).

113

Naar een methode voor het specificeren van kwaliteitseisen

...............

...............

·..

..............

Figuur 7.3: Het 'duivelsvierkant'

De kringloop en het duivelsvierkant hebben aan de basis gelegen van een methode voor het realiseren van kwaliteitseisen die recent door hetSercis ontwikkeld (Serc-Quint 1992). We bespreken kort de essentie van deze methode. In de Serc-Quint methode wordt getracht rekening te houden met de onderlinge wisselwerking tussen kwaliteitseisen. Doel is om duidelijkheid te krijgen in de relaties tussen gespecificeerde kwaliteitseisen en de te nemen maatregelen om kwaliteitseisen te realiseren. De essentie van de Serc-Quint methode kan worden weergegeven aan de hand van figuur 7 .4. In feite betreft het hier een verdere uitwerking van de kwaliteitskringloop volgens (Delen, Kouwenhoven en Rijsenbrij 1991). Er wordt getracht rekening te houden met de afhankelijkheden die bestaan tussen kwaliteitseisen onderling en tussen te nemen maatregelen onderling. Om deze onderlinge (positieve of negatieve) beïnvloeding te ondervangen worden maatregelen geclusterd die een zekere verwantschap vertonen (zie de verticale as in figuur 7.4). De verwantschap heeft betrekking op een gezamelijke positieve of negatieve beïnvloeding van (een) bepaalde kwaliteitseis(en). Daarnaast wordt ook gestreefd naar het clusteren van kwaliteitseisen die elkaar onderling beïnvloeden (zie de horizontale as in figuur 7.4). De clusters kwaliteitseisen en de clusters maatregelen bestaan elk uit respectievelijk een aantal kwaliteitseisen en een aantal maatregelen die in grote lijnen overeen komen met de kwaliteitseisen en maatregelen volgens (Delen, Kouwenhoven en Rijsenbrij 1991). Met behulp van de relatiematrix wordt getracht de talloze verbanden tussen de individuele maatregelen en de individuele kwaliteitseisen te reduceren. Doel is een overzichtelijk

114

Hoofdstuk 7 geheel van positieve (+) en negatieve (-) relaties tussen clusters kwaliteitseisen en clusters maatregelen. portabiliteit degelijkheld veranaerbaarheld

I

ergonomie efficiency

I I

be
modelleren controleren opUnaiiseren

ë

..

.

•

.

+

vamgeven +

tri!.Ce"en

verst.erl:en overdragen

. . +

. +

• + +

Figuur 7.4: Relaties tussen kwaliteitseisen en maatregelen (Serc-Quint 1992) Sleutelwoord in het proces van het realiseren van kwaliteitseisen is het nemen van maatregelen. Voorbeelden van het nemen van maatregelen door een ontwerper zijn respectievelijk het inbouwen van allerlei controles ten behoeve van de bedrijfszekerheid van een informatiesysteem (zie kolom 2 en rij 2 in figuur 7.4), of het inbouwen van 'help'-informatie, kleur en geluid ten behoeve van de ergonomie (onder andere gebruiksvriendelijkheid) van een systeem (zie kolom 4 en rij 4 in figuur 7.4). Het voert te ver om hier uitgebreid in te gaan op de verschillende soorten maatregelen. Daarvoor wordt verwezen naar het betreffende Serc-rapport (Serc-Quint 1992).

7.2.3 Specificeren van kwaliteitseisen Met betrekking tot het specificeren van kwaliteitseisen heeft hoofdstuk 5 laten zien dat de karakterisering op drie dimensies van een gewenst informatiesysteem duidelijk maakt wat de bijbehorende kwaliteitseisen van dat systeem zijn. Ook is duidelijk geworden dat voor enkele kwaliteitseisen een aanvullende analyse nodig is. Hoewel dit enig houvast geeft voor het specificeren van kwaliteitseisen is in dit boek vooralsnog onduidelijk gebleven hoe kan worden bepaald welk type informatiesysteem in een bepaalde bedrijfssituatie nodig is. Gevolgen daarvan zijn onder andere: het type informatiesysteem dat wordt ontwikkeld, wordt eenzijdig door makers bepaald. De kwaliteitseisen die daarop van toepassing zijn worden vastgesteld door makers vanuit een technische invalshoek. Het risico is groot dat de 'echte' behoeften en wensen van de afnemer niet of nauwelijks worden gehoord;

115

Naar een metlwde voor het specificeren van kwaliteitseisen het ontbreekt afnemers aan ondersteuning bij de bepaling welk type informatiesysteem nodig is. Kwaliteitseisen worden ad-hoc opgesomd, prioriteiten kunnen niet worden aangegeven en consequenties qua kosten/baten worden niet overzien. Er ontstaan niet-realistische verwachtingen over te leveren kwaliteit; het maken van afspraken tussen makers en afnemers over het type informatiesysteem en de bijbehorende kwaliteitseisen verloopt problematisch. Er bestaat onduidelijkheid over verantwoordelijkheden en bevoegdheden met betrekking tot dwingende, noodzakelijke en gewenste kwaliteitskenmerk:en van een informatiesysteem. Samengevat kan worden gesteld dat de vraag hoe afnemers en makers te werk moeten gaan bij het bepalen van kwaliteitseisen niet wordt beantwoord. In de navolgende paragrafen van dit hoofdstuk wordt beschreven hoe daarin verbetering kan worden gebracht

7.3 Een benaderingswijze voor het specificeren van kwaliteitseisen Voor het specificeren van eisen van een informatiesysteem worden in de literatuur verschillende benaderingswijzen beschreven. We bespreken kort deze benaderingswijzen die ook wel strategieën voor informatiebehoeftebepaling worden genoemd. Doel is om duidelijk te krijgen op welke punten deze strategieën aanknopingspunten bieden voor het specificeren van kwaliteitseisen.

7.3.1 Benaderingswijzen voor het specificeren van informatiebehoeften In de literatuur wordt besproken hoe men informatiebehoeften kan achterhalen door het volgen van bepaalde strategieën. Uitgangspunt voor het bepalen van een strategie zijn karakteristieken van een bedrijfssituatie en met name het aspect onzekerheid (Davis en 01son 1984, Bemelmans 1991). Er worden door genoemde auteurs vier strategieën onderscheiden die respectievelijk worden omschreven als de oberstrategie, de referentiestrategie, de ontwikkelstrategie en de evolutionaire strategie. In de beschrijving van de strategieën wordt geen onderscheid gemaak tussen het specificeren van functionele eisen en kwaliteitseisen. De oberstrategie heeft betrekking op directe ondervraging van gebruikers met betrekking tot hun behoeften aan informatie. Voor deze strategie kan worden gekozen wanneer gebruikers beperkt in aantal zijn, een hoog kennis en ervaringsniveau hebben en wanneer de informatieproblematiek goed gestructureerd is.

De referentiestrategie is gericht op het gebruik van modellen van bestaande systemen als referentiekader bij het ontwikkelen van nieuwe systemen. In een bepaalde situatie zoekt men naar een geschikt referentiemodel en leidt men op grond daarvan de belangrijkste specificaties af. De referentiestrategie is met name geschikt wanneer men de beschikking heeft over voldoende uitgewerkte en van toepassing zijnde referentiemodellen die een 116

Hoofdstuk 7 goede afspiegeling vonnen van de te ontwikkelen infonnatiesystemen. Verder dient de situatie waarvoor het systeem wordt ontwikkeld redelijk stabiel te zijn in de tijd. De ontwikkelstrategie heeft betrekking op een zorgvuldige analyse en structurering van een besturingssituatie en het te ontwikkelen infonnatiesysteem. Deze strategie is te prefereren in geval referentiemodellen ontbreken, problemen minder goed gestructureerd zijn, en kennis en ervaringsniveau van afnemers (met het oog op het duidelijk beschrijven van hun behoeften en problemen) middelmatig zijn. De evolutionaire strategie betekent dat men een infonnatiesysteem in kleine incrementele stappen ontwerpt en bouwt. In situaties waarin infonnatiebehoeften sterk groeien (en kunnen veranderen) en de onzekerheid met betrekking tot de volledigheid van specificaties groot is verdient deze strategie de voorkeur. Samengevat kan worden gesteld dat in elke strategie (afnemers in) bedrijfssituaties op verschillende manieren worden benaderd om de eisen ten aanzien van een te ontwikkelen infonnatiesysteem te achterhalen. In de hoofdstukken 4 en 5 van dit boek zijn voor het specificeren van kwaliteitseisen reeds twee uitgangspunten beschreven, respectievelijk het uitgangspunt van de karakteristieken van bet type infonnatiesysteem dat moet worden ontwikkeld (hoofdstuk 5) en het uitgangspunt van de samenwerking tussen makers en afnemers om te komen tot, in Juran's tennen: 'fitness for use' of, in tennen van Garvin: 'user based quality' (hoofdstuk 4).

Wanneer we deze uitgangspunten vergelijken met de wijze waarop in de verschillende strateg~n een relatie wordt gelegd tussen de karakteristieken van een bedrijfssituatie en eisen voor een infonnatiesysteem dan kunnen de volgende aanknopingspunten worden beschreven: De oberstrategie benadrukt de communicatie met afnemers. Zoals gesteld in hoofdstuk 4 is communicatie in dit boek een van de uitgangspunten voor het specificeren van kwaliteitseisen. In de referentiestrategie wordt uitgegaan van de karakteristieken (lees: generieke kenmerken) van een bedrijfssituatie. In dit boek is in hoofdstuk 5 beschreven dat voor het afleiden van kwaliteitseisen gebruik kan worden gemaakt van de karakteristieken van een infonnatiesysteem dat moet worden ontwikkeld. In de ontwikkelstrategie wordt gekozen voor een gedetailleerde analyse van de specifieke infonnatiebehoeften in een bedrijfssituatie. Met Bemelmans (1991) stellen we dat kwaliteitseisen generiek van aard zijn waardoor een gedetailleerde analyse van specifieke infonnatiebehoeften minder geschikt is voor het speciflCefen van kwaliteitseisen.

117

Naar een methode voor het specificeren van kwaliteitseisen Met betrekking tot de evolutionaire strategie kan worden gesteld dat een stapsgewijze ontwikkeling goed aansluit bij de kwaliteitsopvatting 'continuons improvement', c.q. het stapsgewijze verbeteren van de functionaliteit en de kwaliteit van een infonnatiesysteem. Samengevat vinden we in alle vier de strategioon aanknopingspunten die kunnen worden gebruikt voor een benaderingswijze voor het specificeren van kwaliteitseisen. Deze aanknopingspunten zijn respectievelijk de betrokkenheid van afnemers, het uitgangspunt van karakteristieken van bedrijfssituaties, en incrementele ontwikkeling en stapsgewijze verbetering. In de navolgende paragraaf beschrijven we op grond van bovenstaande beschouwing een benaderingswijze voor het specificeren van kwaliteitseisen.

7.3.2 De kwallteitskringloop voor bet specificeren van kwaliteitseisen Bij het specificeren van kwaliteitseisen staan de volgende drie punten centraal: Ten eerste: Ten tweede:

Ten derde:

in het specificatieproces dient communicatie met de afnemers plaats te vinden over het type infonnatiesysteem dat nodig is en over hun kwaliteitsbehoeften. de communicatie over kwaliteitsbehoeften dient gericht te zijn op het in kaart brengen van de karakteristieken van een bedrijft- of probleemsituatie. Op grond daarvan dient te worden bepaald welke kwaliteitseisen om welke redenen relevant zijn. terugkoppeling tussen afnemers en makers over gewenste en gerealiseerde kwaliteitseisen is noodzakelijk. Het proces van het specificeren van kwaliteitseisen heeft een cyclisch karakter.

vergelijken

vergelijken

Figuur 7.5: De dubbele kringloop van produktkwaliteit

118

Hoofdstuk 7 Op grond van deze drie punten beschrijven we het omgaan met kwaliteitseisen, niet als één enkele kwaliteitskringloop maar als een dubbele kwaliteitskringloop van specificeren én realiseren (zie figuur 7.5). Evenals de kringloop op het realisatietraject kent de kringloop op het specificatietraject drie objecttypen. Achtereenvolgens zijn deze getiteld: 'kwaliteitsbehoeften', 'situatiekarakteristieken' en 'kwaliteitseisen'. · Sleutelbegrippen in de dubbele kringloop zijn maatregelen en situatiekarakteristieken. Maatregelen zijn nodig om kwaliteitseisen te realiseren als produkteigenschappen, situatiekarakteristieken zijn nodig om uit kwaliteitsbehoeften kwaliteitseisen te kunnen afleiden. Voor wat betreft de realisatiekringloop hebben makers of ontwerpers de beschikking over definitiestelsels van kwaliteitseisen, maatregelen en eigenschappen (Delen, Kouwenhoven en Rijsenbrij 1991, Serc-Quint 1992). Voor wat betreft de specificatiekringloop ontbreekt echter duidelijkheid over relevante situatiekarakteristieken. In de navolgende paragrafen gaan we daar nader op in.

7.4 Quality Function Deployment (QFD): een methode voor het afleiden van eisen uit afnemerbehoeften Zoals beschreven is in paragraaf 7.2 kan op het realisatietraject van het omgaan met kwaliteitseisen gebruik worden gemaakt van een relatiematrix-techniek (Serc-Quint 1992). Voor het specificeren van kwaliteitseisen ontbreken echter concrete werkwijzen en technieken. In deze paragraaf beschrijven we analoog aan de werkwijze op het realisatietraject een relatiematrix voor het specificatietrajecL Deze relatiematrix heeft als doel ondersteuning te bieden bij het afleiden van kwaliteitseisen uit kwaliteitsbehoeften. We maken voor de beschrijving van die relatiematrix gebruik van een methode die in de industrie wordt gebruikt, namelijk de methode Quality Function Deptoyment (Hauser en Clausing 1988). De methode QFD kent in het traject van concepteet ontwerp naar realisatie een aantal fasen. Onderscheid kan worden gemaakt tussen een specificatie- en realisatiefase. Kern van de methode QFD is een 'kwaliteitshuis' ofwel een relatiematrix die in elke fase wordt toegepast om behoeften en wensen v~ afnemers te vertalen naar eigenschappen van een produkt (zie onder andere (Blauw en Oostemoorn 1992)). QFD biedt in de realisatiefase met name ondersteuning aan ontwerpers. In de specificatiefase wordt het kwaliteitshuis gebruikt om de wensen en behoeften van afnemers vast te leggen en te vertalen naar produktspecificaties. QFD biedt daarmee in de eerste fase ondersteuning aan de communicatie tussen afnemers en makers. Omdat bij de ontwikkeling van informatiesystemen in de realisatiefasen reeds ondersteuning bestaat voor het realiseren van kwaliteitseisen (zie voorgaande paragraaf) richten we ons in dit hoofdstuk met name op de ondersteuning die QFD biedt in de specificatiefase. QFD is niet beperkt tot het afleiden van kwaliteitseisen alleen. Alle relevante (zowel functionele als prestatie) -wensen en -eisen van afnemers dienen geïdentificeerd te worden. In de eerste fase worden afnemerbehoeften en -wensen geïnventariseerd. Enerzijds dient duidelijk te worden of de behoeften en wensen van afnemers realistisch zijn en anderzijds 119

Naar een methode voor het specificeren van kwaliteitseisen of de maker mogelijkheden ziet om het gevraagde produkt te ontwikkelen. QFD legt in de eerste fase bij het afleiden van eisen het accent op: - de identificatie en beschrijving van afnemerbehoeften, -wensen en -verwachtingen - het vervolgens relateren van afnemerwensen aan specificaties door middel van een relatiematrix (kwaliteitshuis genoemd) (zie figuur 7.6.)

[

J

afnemerbehoeften

J

Figuur 7.6: Het 'kwaliteitshuis' We bespreken kort het 'kwaliteitshuis'. Vervolgens beschrijven we twee beperkingen die deze matrix heeft voor het specificeren van kwaliteitseisen van informatiesystemen. Het kwaliteitshuis dient als volgt gelezen te worden: in de linkerzijde van de matrix worden de geïnventariseerde afnemerbehoeften geplaatst (afnemerbehoeften worden geformuleerd in de taal van de afnemer); de bovenzijde van de matrix bevat de specificaties waaraan makers dienen te voldoen om tegemoet te. komen aan de afnemerbehoeften (specificaties zijn geformuleerd in 'makers' -taal); de rechterzijde van de matrix wordt benut om geprioriseerde afnemerbehoeften aan te geven; in de top van de matrix worden relaties tussen specificaties aangegeven (om rekening te kunnen houden met de onderlinge (positieve of negatieve) beïn;vloeding tussen specificaties); binnen de matrix worden de relaties tussen afnemerbehoeften en specificaties gelegd; in de onderzijde van de matrix worden uiteindelijk de geprioriseerde specificaties weergegeven.

120

Hoofdstuk 7 We merken op dat specifieke QFD-technieken buiten het kader van dit hoofdstuk vallen. Het gaat hier met name om een werkwijze voor het relateren van afnemerbehoeften en -wensen aan kwaliteitseisen. Voor een gedetailleerde beschrijving van QFD-technieken verwijzen we naar (Hauser en Clausing 1988, Bossert 1991). Het kwaliteitshuis van QFD biedt een algemeen kader voor het specificeren van specificaties uit afnemerwensen. De principes van het in kaart brengen van afnemerwensen en het relateren van afnemerwensen aan specificaties komen overeen met de beschreven werkwijze voor het specificeren van kwaliteitseisen van informatiesystemen. Voor het specificeren van kwaliteitseisen volgens de methode QFD kunnen de volgende beperkingen worden genoemd: hoewel door QFD wordt verwezen naar allerlei bronnen (bijvoorbeeld contact met afnemers, beursbezoek, marktanalyses, interviews, wettelijke regels. milieu-eisen) om afnemerwensen te identificeren biedt het kwaliteitshuis geen ondersteuning bij het op gestructureerde wijze inventariseren van de wensen en behoeften van afnemers (op de verticale as van de matrix); het kwaliteitshuis van QFD beschrijft geen standaardrelaties tussen wensen van afnemers (verticale as) en eisen (horizontale as). Telkens opnieuw dienen per situatie de geïnventariseerde wensen gerelateerd te worden aan de eisen.

In de volgende paragraaf beschrijven we op welke wijze, in analogie met QFD, kwaliteitseisen voor informatiesystemen kunnen worden afgeleid uit kwaliteitsbehoeften. Het betreft het hanteren van een gestructureerde vragenlijst op de verticale as van het kwaliteitshuis.

7.5 Van kwaliteitsbehoeften naar kwaliteitseisen Om te bepalen welk type informatiesysteem met de daarbij behorende kwaliteitseisen in een bepaalde bedrijfssituatie nodig is dient inzicht te ontstaan in die bedrijfssituatie. Zoals hoofdstuk 5 heeft laten zien kan voor het bepalen van kwaliteitseisen gebruik worden gemaakt van de drie dimensies: scope, toestanden en uniekheid van een informatiesysteem. Echter, ook is gebleken in hoofdstuk 5 dat niet alle kwaliteitseisen op deze wijze kunnen worden achterhaald. Gesteld is dat voor de bepaling van enkele kwaliteitseisen een aanvullende analyse nodig is. Daar we ons in dit boek met name richten op informatiesystemen of softwareprodokten in een bestuurlijke omgeving maken we gebruik van een benaderingswijze uit de literatuur om de karakteristieken van een bedrijfssituatie te inventariseren (Bemelmans 1986). Deze benaderingswijze is gebaseerd op het zogeheten FBI-paradigma. waarbij P staat voor het te besturen proces, B voor besturing en I voor informatie. In paragraaf 7.5.1 wordt nader ingegaan op deze benadering waarbij het specifroeren van kwaliteitseisen centraal staat In de paragrafen 7 .5.2 en 7 .5.3 wordt een en ander toegespitst op de ontwikkeling van een

121

Naar een methode voor het specificeren van kwaliteitseisen

methode voor de specificatie van kwaliteitseisen. De kern van die methode wordt gevormd door een checklijst van gespreksonderwerpen over bedrijfssituatiekarakteristieken.

7.5.1 Karakterisering van bedrijfssituaties: Proces-Besturing.:.htformatie Bemelmans (1986) beschrijft de samenhang tussen de karakteristieken van een te besturen bedrijfsproces, de karakteristieken van de besturing van dat proces en het informatiesysteem dat voor die besturing nodig is. Een en ander is uitgewerkt als het PBI-paradigma (Proces-Besturing-Informatie). Volgens het PBI-paradigma dienen de eisen voor een informatiesysteem te worden bepaald op grond van een beschrijving van h!'t proces en de daarbij behorende besturing. Met betrekking tot kwaliteitseisen van ifltormatiesystemen wordt gesteld dat deze, in tegenstelling tot functionele eisen, meer generibk van aard zijn en afhangen van het type besturingssituatie. Door karakteristieken van eeh bedrijfssituatie te hesehijven kan duidelijkheid worden verkregen over te stellen kwaliteitseisen aan een informatiesysteem.

De theoretische achtergrond van het PBI-model is gebaseerd op karakteristieken die de moeilijkheidsgraad van de besturing bepalen. We geven in deze paragraaf eerst kort een overzicht van deze besturingskarakteristieken en vervolgens beschrijven . we een daarop gebaseerde werl.cwijze voor het inventariseren van de karakteristieken van een proces. In het vervolg van dit hoofdstuk vormen de besturingskarakteristieken tezamen met de genoemde werl.cwijze voor het inventariseren van de karakteristieken van een proces de basis voor een methode voor het specificeren van kwaliteitseisen. Door (de Leeuw 1974) wordt de moeilijkheidsgraad van de besturing als ipvalshoek genomen om besturingssituaties te typeren. De Leeuw ordent de besturing binnbn bedrijfssituaties naar twee gezichtspunten, respectievelijk het gezichtspunt van de gerichtheid van de besturing (onderscheid wordt gemaakt tussen interne en externe sturing), en het gezichtspunt van de aard van de besturing (onderscheid wordt gemaakt tussen routinematige, adaptieve en strategische sturing). Beschreven wordt hoe de moeilijkheidsgraad toeneemt wanneer de besturing verschuift van intern naar extern en van routinematig naar strategisch. Door (Bemelmans 1991) worden de volgende karakteristieken van de moeilijkheidsgraad van een besturingssituatie onderscheiden: het aantal variabelen en de samenhang daartussen (die relevant zijn voor de betreffende besturingssituatie) de beheersbaarheid en de voorspelbaarheid van de variabelen de gevoeligheid en de stabiliteit van het bestuurde systeem het reactiepatroon van het bestuurde systeem en het besturende orgaan ' We merken op dat deze karakteristieken van de moeilijkheidsgraad van besturingssituaties worden teruggevoerd op systeemvariabelen en hun eigenschappen. Onderscheid wordt gemaakt tussen reguliere, irreguliere, invoer-, uitvoer-, doel- en stuurvariabelen en de 122

Hoofdstuk 7 eigenschappen van die variabelen (bijvoorbeeld de voorspelbaarheid, de beheersbaarheid etcetera). We lichten de karakteristieken die bepalend zijn voor de moeilijkheidsgraad van de besturing, verder toe in paragraaf 7.5.2, vervolgens bespreken we enkele relaties met kwaliteitseisen zoals die in de literatuur (Bemelmans 1991) zijn beschreven en formuleren we onderwerpen voor een checklijst van vragen om kwaliteitseisen te bepalen. De karakteristieken van het te besturen proces worden vanuit de volgende invalshoeken beschreven: - de statische grootheden: - de produkt/marktkenmerken - de produktiemiddelenkenmerken - de dynamische grootheden: - de proces- en gedragskenmerken

Voor het in kaart brengen van de karakteristieken van het te besturen proces is in (Bemelmans 1986) de volgende checklijst opgesteld: Produkt/markt-kenmerken het aantal verschillende eindprodokten of -diensten dat wordt geproduceerd de samengesteldheid van die prodokten en/of diensten de specificiteit van eindprodokten het dynamisch karakter van de vraag naar eindprodokten de voorspelbaarheid van de vraag naar eindprodokten de economische waarde van prodokten Produktiemiddelenkenmerken het aantal verschillende produktiemiddelen de specificiteit van produktiemiddelen het dynamisch karakter van het aanbod van produktiemiddelen de voorspelbaarheid van het aanbod de economische waarde van het produktiemiddel Kenmerken van het produktieproces aantal verschillende bewerkingen samenhang tussen bewerkingen specificiteit van bewerkingen dynamisch karakter van bewerkingen voorspelbaarheid van de dynamiek economische waarde van de bewerkingen De checklijst geldt in het algemeen voor het inventariseren van de karakteristieken van een proces binnen een bepaald bedrijfssysteem. In paragraaf 7.5.3 maken we gebruik van deze lijst om te komen tot een checklijst voor het bepalen van de karakteristieken van een informatiesysteem op drie dimensies en voor de specificatie van relevante kwaliteitseisen.

123

Naar een methode voor het specificeren van kwaliteitseisen In de navolgende paragraaf 7.5.2 bespreken we kort de aanzet uit (Bemelmans 1991) waarbij wordt uitgegaan van karakteristieken van besturingssituaties om kwaliteitseisen te specificeren.

7.5.2 Oriëntatie op de moeilijkheidsgraad van de besturing De moeilijkheidsgraad van een besturingssituatie wordt bepaald door de volgende karakteristieken: het aantal variabelen en de samenhang daartussen (die relevant zijn voor de betreffende besturingssituatie) de beheersbaarheid en de voorspelbaarheid van de variabelen de gevoeligheid en de stabiliteit van het bestuurde systeem het reactiepatroon van het bestuurde systeem en het besturende orgaan Met betrekking tot het aancal variabelen wordt onderscheid gemaakt tussen irreguliere, stuur- en doelvariabelen. Irreguliere variabelen representeren omgevingsinvloeden. Stuurvariabelen hebben betrekking op regelen, wijzigen en bijstellen binnen een besturingssituatie. Doelvariabelen hebben betrekking op de na te streven doelstellingen van een besturingssituatie. Naarmate het aantal variabelen dat een rol speelt groter is, en de samenhang tussen de variabelen groter is, is een systeem moeilijker te besturen. In plaats van gedetailleerde en nauwkeurige informatie over individuele variabelen bestaat meer behoefte aan informatie over globale onderlinge relaties en onderlinge beYnvloeding van variabelen. De kwaliteit van een informatiesysteem wordt in deze besturingssituatie in belangrijke mate bepaald door de selectie- en de aggregatiemogelijkheden van de gegevens. Vertaald .naar kwaliteitseisen betekent dit dat hoge eisen worden gesteld aan de bruikbaarheid vat) de informatie, ofwel de effectiviteit van informatie, die wordt verstrekt. Daarnaast worden hoge eisen gesteld aan gebruiksvriendelijkheid van een informatiesYsteem. In figuwi 7. 7 zijn deze kwaliteitseisen in relatie tot de besturingskarakteristieken 'aantal variabelen' en 'samenhang tussen variabelen' weergegeven in een relatiematrix. Uitgangspunt op de verticale as van deze relatiematrix zijn gespreksondet'werpen aan de hand waarvan de karakteristieken van een besturingssituatie kunnen worden, bepaald. Overeenkomstig het kwaliteitshuis van QFD staan op de horizontale as de kwaliteitseisen weergegeven. In deze figuur is gebruik gemaakt van de opsomming van kwaliteitseisen volgens (Bemelmans 1991). In de cellen van de relatiematrix zijn de relaties tussen de onderwerpen (besturingskarakteristieken) en de kwaliteitseisen aangegeven door middel van een 'kruis'.

124

Hoofdstuk 7

Kwaliteitseisen

Besturlngskarakterist leken

tijdigheld

lntq~

tilt

111111111'1111'-n

..... .....

.....

~t-

-_.,....._ x x x x xx 'llll')!!!>oien

"_ "_

... _"

-~ llglnfl

daelnlttigheld

xx efffiCo t!VII.elt

.......

Oll:nlb- ~-~ deiJ
onder-

lloorheld

test·

lloorhold

=

lnte-

er~

lnposlloorhold

-

~

xx

-·

..... .....

~

·-· ·-

sto!!ltelt

•.. .....

reactiepatroon

..... .....

x

Figuur 7.7: Een relatiematrix voor de. verbanden tussen besturingskarakteristieken en kwaliteitseisen Als voorbeelden van gespreksonderwerpen om duidelijkheid te verkrijgen over de besturingskarakteristieken 'aantal variabelen' en 'samenhang van variabelen' worden genoemd: de aard van de beslissingen die moeten worden genomen (strategisch, tactisch, routinematig) de doelstellingen waaraan bij de besturing moet worden voldaan het aantal alternatieven dat men heeft om een verstoord systeem bij te regelen de behoefte aan informatie uit de omgeving de mate waarin informatie in geaggregeerde vorm beschikbaar moet worden gesteld de behoefte aan geavanceerde selectiemogelijkheden (bijvoorbeeld queries) de mate van vertrouwelijkheid van gegevens Op grond van dergelijke gespreksonderwerpen kan worden bepaald of effectiviteit en gebruiksvriendelijkheid belangrijke kwaliteitseisen zijn en waarom het belangrijke eisen zijn. De beheersbaarheid van variabelen in een besturingssituatie hangt samen met de mate waarin variabelen zich ootrekken aan de beslissingsmacht van de beslisser zelf. De voorspelbaarheid van variabelen wordt onder andere bepaald door de mate van meetbaarheid van de variabelen en de effecten in de tijd van het hanteren van stuurvariabelen (ook wel de tijdshorizon van beslissingen genoemd).

125

Naar een methode voor het specificeren VDIJ kwaliteitseisen Naarmate de beheersbaarheid en voorspelbaarheid van variabelen afnemen dienen hogere eisen te worden gesteld aan onder andere de responsesnelheid van een informatiesysteem (responsesnelheid is een deeleis van de kwaliteitseis tijdigheid). Naarmate de variabelen van een te besturen systeem minder voorspelbaar en beheersbaar zijn en men variabelen minder kan beïnvloeden, wordt de besturing moeilijker. De relatie tussen ~Ieze besturingskarakteristieken en de kwaliteitseis tijdigheid is weergegeven in de relatiematrix in figuur 7.7. Als voorbeelden van gespreksonderwerpen om uit de karakteristieken 'beheersbaarheid' en 'voorspelbaarheid' kwaliteitseisen te kunnen afleiden worden genoemd: de onzekerheid in beslissingsproblemen de tijdshorizon van beslissingen de meetbaarheid van beslissingsvariabelen Op grond van dit soort gespreksonderwerpen kan worden vastgesteld of en waarom 'tijdigheid' een belangrijke kwaliteitseis is in een bepaalde besturingssituatie.

De gevoeligheid van een bestuurd systeem heeft betrekking op de mate waarin een besturingssituatie gevoelig is voor verstorende invloeden van buitenaf (irreguliere variabelen). De stabiliteit van een bestuurd systeem wordt omschreven als de mate waarin een te besturen systeem in de tijd onveranderd blijft ten opzichte van de begintoestand van dat systeem. Het reactiepatroon heeft betrekking op de mate van wisselvalligheid waarmee een te besturen systeem verstoord raakt in de tijd.

Met betrekking tot kwaliteitseisen voor een informatiesysteem voor de besturing van een gevoelig en relatief instabiel bestuurlijk informatiesysteem kan worden ge~teld dat het in deze situatie noodzakelijk is om snel en nauwkeurig te kunnen reageren op omgevingsinvloeden. Er gelden hogere eisen aan de integriteit en de tijdigheid van een informatiesysteem, zie figuur 7.7. Met betrekking tot een systeem dat wisselvallig verstoord raakt geldt dat waarschuwingsignalen en adviezen over stuuracties belangrijk zijn qua vormgeving, frequentie en verstaanbaarheid. Met andere woorden dient in het bijzonder aandacht te worden besteed aan de kwaliteitseis gebruiksvriendelijkheid, zie figuur 7.7. Als voorbeelden van gespreksonderwerpen om uit deze besturingskarakterlstieken kwaliteitseisen te kunnen afleiden noemen we: de mate waarin gebeurtenissen in de omgeving de besturingssituatie beïnvloeden de mate waarin inputvariabelen constant blijven in de tijd de mate waarin behoefte bestaat aan het maken van prognoses van het gedrag van het systeem bij gewijzigde en ongewijzigde besturing de mate waarin behoefte bestaat aan extra aandacht voor vormgeving, frequentie, verstaanbaarheid van waarschuwingssignalen en adviezen over stuuracties

126

Hoofdstuk 7

In het bovenstaande is een aanzet uit de literatuur besproken om kwaliteitseisen af te leiden uit karakteristieken van besturingssituaties. De beschreven aanpak leidt tot meer inzicht in de relaties tussen besturingskarakteristieken en kwaliteitseisen. Zoals figuur 7.7 Iaat zien betreft het slechts een beperkt aantal kwaliteitseisen, namelijk tijdigheid, integriteit, effectiviteit en gebruiksvriendelijkheid. Van twee van deze kwaliteitseisen, te weten tijdigheid en integriteit kon de relevantie niet worden aangetoond aan de hand van de drie dimensies van de scope, de toestanden en de uniekheid van een informatiesysteem of softwareprodukt, zie hoofdstuk 5. Dit betekent dat een beschrijving van de karakteristieken van een besturingssituatie een belangrijke aanvulling is op de aanpak uit hoofdstuk 5 om de relevantie van kwaliteitseisen te kunnen bepalen.

In hoofdstuk 5 zijn relaties tussen produktkarakteristieken en kwaliteitseisen beschreven. Voor elk van de drie dimensies van de scope, de toestanden en de uniekheid van een produkt zijn relevante kwaliteitseisen besproken. Dit vormt het uitgangspunt voor de volgende pragraaf. Centraal staat daar de vraag hoe op grond van karakteristieken van de bedrijfssituatie kan worden bepaald welk type informatiesysteem of softwareprodukt gewenst of noodzakelijk is, en vervolgens te kunnen bepalen welke de relevante kwaliteitseisen zijn.

7.5.3 Oriëntatie op het te besturen proces Om de karakteristieken te bepalen van een gewenst informatiesysteem en de daarbij behorende kwaliteitseisen richten we ons in deze paragraaf op de te besturen processen binnen een bedrijfssituatie. Aan de hand van de checklijst uit paragraaf 7 .5.1 bepalen we gespreksonderwerpen om een informatiesysteem te dimensioneren qua scope, te doorlopen toestanden en uniekheid. Per informatiesysteemdimensie worden uit de checklijst van paragraaf 7.5.1 gespreksonderwerpen geselecteerd uit de input/output (produkt/markt)-categorie, de produktiemiddelencategorie en de produktieprocescategorie. Daarnaast zijn per informatiesysteemdimensie een aantal vragen toegevoegd die verband houden met de vragen uit de checklijst maar die expliciet gericht zijn op het gebruik van een informatiesysteem binnen het te besturen proces. Deze vragen, die zijn aangegeven met een '*', zijn gebaseerd op een empirisch onderzoek naar het specificeren van kwaliteitseisen (Heemstra, Kusters, Tierolf en Trienelrens 1993). Tevens is gebruik gemaakt van (van den Berg en Trienekens 1993).

Als scope van een informadesysteem zijn in hoofdstuk 5 onder andere genoemd: software op zich, software plus documentatie, informatiesysteem. Kwaliteitseisen verschillen met de breedte van de scope van een binnen een bedrijfssituatie gewenst informatiesysteem. In hoofdstuk 5 is beschreven dat de gewenste scope van een informatiesysteem breder is wanneer het systeem meer relaties heeft met de omgeving, wanneer meer gebruikers het systeem benutten etcetera. Met behulp van de checklijst van paragraaf 7.5.1 selecteren we een aantal gespreksonderwerpen. Doel is om nauwkeuriger te kunnen bepalen en onderbouwen wat de gewenste breedte van de scope van een informatiesysteem is.

127

Naar een methode voor het specificeren van lcwaliteitseisen Input/output-kenmerken: het aantal relaties tussen het bedrijfssysteem en de omgeving het aantal verschillende prodokten dat door het bedrijfssysteem moet worden geproduceerd

*

* *

*

het deel van de taken binnen een bedrijfssysteem dat moet worden ondersteund door een informatiesysteem de mate waarin een gevvenst informatiesysteen moet wo.J,"den ingebed in een administratief netvverk de mate waarin een bedrijfssysteem afhankelijk is van gegevens uit andere bedrijfssystemen de mate van complexiteit van gegevensuitvvisseling met andere bedrijfssystemen

Produktiemiddelenkenmerken: het aantal verschillende specialismen dat werkzaam is binnen een bedrijfssysteem de mate van specialisatie van de medewerkers binnen een bedrijfssysteem

* * * *

het aantal medewerkers dat moet worden ondersteund door een informatiesysteem het kennis- en ervaringsniveau van medewerkers het scholingsniveau van medewerkers de mate van homogeniteit van de groep medewerkers qua kennis, ervaring en scholingsniveau

Produktieproceskenmerken: de samenhang tussen bewerkingen binnen een bedrijfssysteem het aantal verschillende bewerkingen binnen een bedrijfssysteem I

* * *

de mate van complexiteit van bewerkingen die een informatiesysteem moet ondersteunen het aantallocaties waar een informatiesysteem gebruikt gaat worden de tijdsduur dat een informatiesysteem gebruikt moet kunnen worden

Op basis van deze gespreksondervverpen dient een genuanceerd beeld te ontstaan van de vereiste scope van een informatiesysteem binnen een bedrijfssituatie. . Bijvoorbeeld wanneer binnen een bedrijfssituatie het aantal relaties met de omgeving groot is, er veel verschillende specialismen worden uitgeoefend en de samenhang tussen de bewerkingen groot is dan kan over het algemeen niet worden volstaan met 'sofrvvare op zich'. Bij de ontvvikkeling van een softvvareprodukt dient rekening te worden gehouden met de inbedding van het systeem in de organisatie, ofwel met de omgeving van het softvvareprodukt. Relevante kwaliteitseisen zijn beveiliging, gebruiksvriendelijkheid en effectiviteit van informatie.

128

Hoofdstuk 7

In figuur 7.8 is aangegeven dat de bovengenoemde gespreksonderwerpen op de verticale as van een relatiematrix worden geplaatst. In de cellen van de relatiematrix zijn de relaties aangegeven tussen kwaliteitseisen en produktkarakteristieken (op de dimensies scope, toestanden en uniekheid van een produkt) zoals deze zijn beschreven in hoofdstuk 5. In deze figuur is gebruik gemaakt van de opsomming van kwaliteitseisen volgens (Bemelmans 1991). We merken op dat de lege rij in de relatiematrix voor 'software op zich' niet betekent dat voor dit soort prodokten geen kwaliteiteisen gelden. Bijvoorbeeld dient aan vanzelfsprekende behoeften van afnemers en aan algemeen aanvaarde normen te worden voldaan. Echter op grond van de produktomschrijving 'software op zich' kunnen geen uitspraken worden gedaan over kwaliteitseisen die met name relevant zijn. Primair proces l:arakterlstiel:en

Input/output

.... middelen .... proces .... .... input/output .... ''''

''''

,,,,

mlddelen ''''

OIO I

proces ''''

Input/output

0 p

E

T 0 E

5 T

A N

D E N

u

middelen

I(

,,,,

H

proces

I

.... ,,,,

-~ -~ ··~g

tett

=. ~ZICh

te.tla

.,.._

ntcrnt51

N I

lOOI

::.r

doemat,Pld

offoc-

, ...tt

......

E

--Üll

~

~IIMrlng

-~nofnnto

E

D

ota-.t

IX

·- --- -d =- -

g......... flab~ dtlljdla~

ooft....

5

c

,,,,

lOOI

Kw a Iite itse isen

Produktdimensies

x ~x

test-

bwheld

~

hr· l::!;.ld llrul<-

x x x~ xlX x x~ x ~

xx

~

xx

x~~

x

Figuur 7.8: De relatiematrix voor de verbanden tussen karakteristieken van het te besturen proces en kwaliteitseisen Als toestanden die een informatiesysteem kan doorlopen zijn in hoofdstuk 5 onder andere genoemd: de toestanden van een produkt vóór oplevering, de toestanden tijdens invoering en de toestanden van een produkt ná oplevering. De relevantie van kwaliteitseisen varieert met het aantal toestanden dat een informatiesysteem doorloopt en waarvoor men als ontwikkelaar verantwoordelijk is. In hoofdstuk 5 is beschreven dat een informatiesysteem of softwareprodukt meer toestanden doorloopt als de bedrijfssituatie waarin het systeem wordt gebruikt frequent aan veranderingen onderhevig is. Met behulp van de gespreksonderwerpen uit de checklijst selecteren we een aantal gespreksonderwerpen. Doel is om nauwkeuriger te kunnen bepalen en

129

Naar een methode voor het specificeren van kwaliteitseisen onderbouwen wat het aantal toestanden is dat een informatiesysteem moet doorlopen en waarvoor men als ontwikkelaar verantwoordelijkheid moet nemen. Input/output-kenmerken: de veranderingen in de vraag naar eindprodukten binnen een bedrijfssysteem de voorspelbaarheid van de vraag naar eindprodutten

*

de mate van stabiliteit van de gegevens die door de informatiesystemen binnen een bedrijfssysteem worden gebruikt

Produktiemiddelenkenmerken: de veranderingen in het aanbod en de beschikbaarheid van werknemers en andere produktiemiddelen de voorspelbaarheid van het aanbod van produktiemiddelen in een bepaald bedrijfssysteem

*

*

de mate waarin veranderingen in de informatietechnologi~ leiden tot behoeften aan andere typen produktiemiddelen de mate waarin veranderingen binnen een bedrijfssysteem leiden tot hogere eisen aan kennis van informatietechnologie van medewerkers

Produktieproceskenmerken: het aantal veranderingen per tijdseenheid van bewerkingen in het bedrijfssysteem . de voorspelbaarheid van de veranderingen in bewerkingsprÓcessen

*

de aard van de veranderingen in een bedrijfssysteem en hun gevolgen voor de gewenste ondersteuning door een informatiesysteem

Aan de hand van deze gespreksonderwerpen dient een genuanceerd beeld te ontstaan van het vereiste aantal te doorlopen toestanden van een informatiesysteem. Vervolgens kunnen de relevante kwaliteitseisen worden vastgesteld, zie figuur 7.8. Bijvoorbeeld voor een bedrijfssituatie waarin veel veranderingen optreden in de vraag naar eindprodukten, waarin de beschikbaarheid van werknemers varieert. en veel veranderingen optreden in het bedrijfssysteem kan niet worden volstaan met een softwareprodukt waarvan door ontwikkelaars alleen de verantwoordelijkheid wordt gedragen voor produkttoestanden tot aan oplevering. Bij de ontwikkeling van het softwareprodukt dient rekening te worden gehouden met aanpassing en/of evolutie op grond van veranderingen in het bedrijfssysteem. Relevante kwaliteitseisen zijn onder meer flexibiliteit. onderhoudbaarheid, integreerbaarbeid en inpasbaarheid. 1

Evenals dat voor de produktscope het geval was bevat het produkttoestandengedeelte van de relatiematrix een lege rij, namelijk voor de toestanden die worden doorlopen vóór 130

Hoofdstuk 7 oplevering van een produkt. Ook hier betekent dit niet dat voor dit soort produkten geen kwaliteitseisen zouden gelden. Uiteraard moet altijd worden voldaan aan minimumeisen en vanzelfsprekende behoeften. Echter op grond van de produktomschrijving 'toestanden vóór oplevering' kunnen geen uitspraken worden gedaan over kwaliteitseisen die met name relevant zijn voor een afnemer. Als gradaties van de uniekheid van een informatiesysteem zijn in hoofdstuk 5 respectievelijk genoemd: een afnemerspecifiek informatiesysteem, een informatiesysteem gebaseerd op referentiemodellen, en een standaard informatiesysteem. Kwaliteitseisen verschillen met de mate van uniekheid van een binnen een bedrijfssituatie gewenst informatiesysteem.

In hoofdstuk 5 is beschreven dat de gewenste mate van uniekheid van een informatiesysteem groter is wanneer werkwijzen binnen een bedrijfssysteem minder gestandaardiseerd zijn, minder formeel kunnen worden beschreven etcetera. Met behulp van de checklijst selecteren we een aantal gespreksonderwerpen. Input/output-kenmerken: de specificiteit van de eindprodukten van het bedrijfssysteem

* *

de mate waarin er binnen de organisatie standaards zijn opgesteld op het gebied van gegevensbeheer en informatietechnologie de mate waarin (soortgelijke) eindprodutten ook in andere bedrijfssystemen worden geproduceerd

Produktiemiddelenkenmerken: de specificiteit van de produktiemiddelen binnen het bedrijfssysteem

* * *

de bereidheid van mensen tot standaardiseren de mate waarin de mensen hun werk als uniek (wensen te) beschouwen het bestaan van informatiereferentiemodellen voor een bedrijfssysteem (en de omgeving daarvan)

Produktieproceskenmerken: de specificiteit van de bewerkingen binnen het bedrijfssysteem

*

*

de mate waarin het werk binnen een bedrijfssysteem formeel kan worden beschreven de mate waarin de relaties met andere werkgebieden zijn geformaliseerd

Op basis van deze gespreksonderwerpen dient een genuanceerd beeld te ontstaan van de vereiste mate van uniekheid van een informatiesysteem. De daarbij behorende relevante kwaliteitseisen kunnen vervolgens worden vastgesteld, zie figuur 7 .8. Bijvoorbeeld voor een bedrijfssituatie waarin unieke produtten worden geproduceerd, en de produktiemiddelen evenals de bewerkingen zeer specifiek van aard zijn kan over het algemeen niet worden volstaan met een standaard softwareprodukt. Het softwareprodukt zal 131

Naar een methode voor het specificeren van kwaliteitseisen

moeten worden toegesneden op de specifieke behoeften van afnemers. Relevante kwaliteitseisen zijn gebruiksvriendelijkheid en effectiviteit. Bedrijfssituaties waarin sprake is van generieke eindproduk:ten en waarin bewerkingen procedureel zijn vastgelegd lenen zich over het algemeen meer voor toel>assing van een standaard informatiesysteem. Relevante kwaliteitseisen voor zo'n informatiesysteem zijn onder meer herbruikbaarheid en overdraagbaarheid. Conclusies Door een oriëntatie op de karakteristieken van de besturing en de karakteristieken van de te besturen processen binnen een bedrijfssituatie worden indicaties verkregen van de relevantie van kwaliteitseisen voor een gewenst of noodzakelijk informatiesysteem of softwareprodukt. Om de bedrijfskarak:teristieken te kunnen vaststellen zijn een groot aantal gespreksonderwerpen op gestructureerde wijze bepaald. Voor gespreksonderwerpen om de relaties te bepalen tussen besturingskarakteristieken en kwaliteitseisen werd gebruik gemaakt van het PBI-model, zie paragraaf 7.5.2. Voor gespreksonderwerpen om de relaties te bepalen tussen karakteristieken van te besturen processen en kwaliteitseisen werd in paragraaf 7.5.3 naast het PBI-model gebruik gemaakt van de drie dimensies van de scope, de toestanden en de uniekheid van een informatiesysteem. Voor een verdere invulling en detaillering van gespreksonderwerpen werd gebruik gemaakt van en verwezen naar (Heemstra, Kusters, Tierolfen Trienekens 1993) en (van den Berg en Trienekens 1993). Met uitzondering van de gespreksonderwerpen uit de PBI-checklijst uit. paragraaf 7.5.1 over de economische waarde (van produkten, produktiemiddelen en produktieprocessen) zijn alle gespreksonderwerpen toegepast om een informatiesysteem te karakteriseren op de drie dimensies van respectievelijk de scope, de toestanden en de uniekheid. Vragen met betrekking tot de economische aspecten van een proces kunnen uitsluitse~ geven over de wenselijkheid c.q. noodzaak van een informatiesysteem vanuit een be4rijfseconomisch perspectief. Dit valt buiten het kader van dit boek. De kwaliteitseis doelmatigheid is de enige eis die niet is afgedekt in de relatiematrices van

figuur 7.7 en figuur 7.8. We verklaren dit als volgt. Doelmatigheid als kwaliteitseis heeft betrekking op de wijze waarop en de mate waarin afwegingen worden gemaakt (lees: gebalanceerd wordt) tussen elke eis (van zowel type functioneel als type kwaliteit) en kosten en inspanningen. In tegenstelling tot alle andere kwaliteitseisen die kunnen worden vertaald in attributen en eigenschappen van een informatiesysteem als produkt moet de kwaliteitseis doelmatigheid voor een belangrijk deel herleid worden op procesaspecten van het ontwikkelwerk. Zoals eerder gesteld valt proceskwaliteit buiten het kader van dit hoofdstuk. Voor de relevantie van de kwaliteitseisen effectiviteit en gebruiksvriendelijkheid in een bepaalde bedrijfssituatie worden zowel indicaties verkregen door de karakteristieken te beschrijven van de moeilijkheidsgraad van de besturing (figuur 7.7) als door de karakteristieken te beschrijven van de te besturen processen (figuur 7 .8). 132

Hoofdstuk 7 Belangrijk verschil tussen de in deze paragraaf beschreven relatiematrices en het QFDkwaliteitshuis, zoals beschreven in paragraaf 7.4, is dat op de verticale assen ondersteuning wordt geboden voor het identificeren van bedrijfssituatiekarakteristieken, respectievelijk de karakteristieken die de moeilijkheidsgraad van de besturing bepalen (figuur 7.7) en de karakteristieken van het te besturen proces (figuur 7.8). Daarmee kunnen de kwaliteitsbehoeften ten aanzien van informatiesystemen van afnemers worden vertaald in kwaliteitseisen van een informatiesysteem. Een tweede verschil tussen de relatiematrices en het kwaliteitshuis volgens QFD is dat de relatiematrices 'vaste' (dat wil zeggen geïdentificeerde) relaties bevatten tussen bedrijfssituatiekarakteristieken en de daarvoor relevante kwaliteitseisen voor een informatiesysteem.

7.6 Samenvatting en conclusies In literatuur en praktijk is vaak gesteld dat ontwikkelaars zich voornamelijk richten op het specificeren en realiseren van functionele eisen. Sinds kort bestaan er op het realisatietraject van systeemontwikkeling enkele aanzetten voor het vertalen van reeds gespecificeerde kwaliteitseisen naar produktkenmerken (Delen, Kouwenhoven en Rijsenbrij 1991, SercQuint 1992). Echter, op het specificatietraject ontbrak tot nu toe adequate ondersteuning om kwaliteitseisen te specificeren.

In dit hoofdstuk is aan de hand van een dubbele kwaliteitskringloop eerst een benaderingswijze beschreven voor het specificeren van kwaliteitseisen. Daarbij is uitgegaan van de strategieën voor het specificeren van functionele eisen (informatiebehoeftebepaling) die in de literatuur worden beschreven (Davis en Olson 1984). In de benaderingswijze voor het specificeren van kwaliteitseisen staan centraal de begrippen kwaliteitsbehoeften en bedrijfssituatiekarakteristieken. Communicatie tussen afnemer en maker is noodzakelijk over de karakteristieken van een bedrijfssituatie waarin een informatiesysteem nodig is. Vervolgens is in dit hoofdstuk op gestructuureerde wijze een lijst met gespreksonderwerpen ontwikkeld ter ondersteuning van die communicatie. Gebruik is gemaakt van de FBI-benadering voor het analyseren van bedrijfssituaties. Enerzijds bestaat de lijst uit gespreksonderwerpen om de moeilijkheidsgraad van de besturing te bepalen. Op grond daarvan kan de relevantie van enkele kwaliteitseisen worden vastgesteld. Anderzijds bestaat de lijst uit gespreksonderwerpen om de te besturen processen binnen een bedrijfssysteem te karakteriseren. Op grond daarvan dient het gewenste informatiesysteem te worden getypeerd op drie produktdimensies waarna de relevante kwaliteitseisen kunnen worden vastgesteld. De dubbele kringloop van produktkwaliteit, de relatiematrices en de lijsten met gespreksonderwerpen (over de besturingskarakteristieken en de te besturen processen) representeren tezamen een methode voor het identificeren en specificeren van kwaliteitseisen. Deze methode sluit 'naadloos' aan op reeds bestaande methoden voor het realiseren van kwaliteitseisen, volgens (Delen, Kouwenhoven en Rijsenbrij 1991) en (Serc-Quint 1992). Bij de ontwikkeling van de methode voor het specificeren van kwaliteitseisen is rekening gehouden met reeds bestaande benaderingswijzen en technieken, bijvoorbeeld de strategi~n voor het bepalen van informatiebehoeften en de methode QFD. Doel is dat de methode daardoor

133

Naar een methode voor het specificeren van kwaliteitseisen

goed ingepast kan worden in het bestaande instrumentarium voor het ontwikkelen van infonnatiesystemen. In de praktijk is een methode voor het specificeren van kwaliteitseisen reeds met succes toegepast. In tegenstelling tot de lijst van gespreksonderwerpen die in dit hoofdstuk op theoretische wijze tot stand kwam werd in de praktijk een vragenlijst gebruikt die op empirische wijze is ontwikkeld (Heemstra, Kusters, Tierolf en Trienekens, 1993, 1994). Uiteraard vertonen de lijst van. gespreksonderwerpen en de empirisch bepàalde vragenlijst vele overeenkomsten. Door verdere toepassing van de methode in verschillende bedrijfsituaties dient de methode te evolueren naar een volwaardig instrument. De methode dient dan een eenduidige en consistente vragenlijst te bevatten die hanteerbaar is voor zowel makers als afnemers.

134

8

NABESCHOUWING

8.1 Samenvatting en resultaten Doel van dit boek is een bijdrage te leveren aan het bespreekbaar en hanteerbaar maken van het begrip kwaliteit bij het ontwikkelen van informatiesystemen. VerschiJlende soorten kwaliteitsopvattingen zijn geordend en nader beschreven. Om kwaliteit hanteerbaar te maken is een methode ontwikkeld voor het specificeren van kwaliteitseisen. Het eerste deel van dit boek (hoofdstuk 1 en 2) beschrijft de aanleidingen voor deze studie. Gerapporteerd wordt over de verschillende opvattingen over kwaliteit in literatuur en praktijk. Samengevat kan als 'hoofd' -aanleiding worden genoemd het toenemende belang van kwaliteit in de informatiesystemen- en software-wereld enerzijds en het ontbreken van eenduidigheid en duidelijkheid over kwaliteit en kwaliteitsbeheersing anderzijds. Uit een inventarisatie van de literatuur over kwaliteit blijkt dat in de software-industrie de jaren negentig worden bestempeld als het kwaliteitstijdperk (Basili en Musa 1991). Het beheersen van het ontwikkelwerk op alleen tijd en kosten is te eenzijdig en te beperkt. Ook het alleen gericht zijn op de realisatie van een bepaalde functionaliteit leidt niet tot de gewenste tevredenheid bij de afnemer. Een oplossing dient te worden gezocht in het concretiseren van kwaliteit (Fenton 1991). Omgaan met kwaliteit en kwaliteitsbeheersing dienen volwaardige componenten van het ontwikkelwerk te worden. Hoofdstuk 2 bespreekt de resultaten van een praktijkonderzoek in Nederland naar problemen en knelpunten bij informatiesysteemontwikkeling (Trienekens en van Reeken 1992). Praktijkmensen blijken met name behoefte te hebben aan gerichte verbeteringen binnen de bestaande aanpakken en werkwijzen. Men ziet momenteel af van het organisatiebreed introduceren van geheel nieuwe werkwijzen of het uitgebreid experimenteren met volledig nieuwe concepten. Praktijkmensen streven naar een evenwichtige uitbreiding en geleidelijke verbetering van hun kennis- en middelenarsenaal. Integratie van denk- en werkwijzen en flexibiliteit in het toepassen van methoden en technieken zijn daarbij sleutelwoorden. Vraag is hoe het 'kwaliteitsdenken' daaraan een bijdrage kan leveren. Het ordenende tweede deel van dit boek omvat de hoofdstukken 3 en 4. In hoofdstuk 3 wordt een samenhangend beeld van systeemontwikkeling gepresenteerd. Achterliggende gedachte is dat eerst een zo volledig mogelijk kader van systeemontwikkeling nodig is voordat duidelijk kan worden gemaakt wat de plaats en de rol van kwaliteit en kwaliteitsbeheersing daarbinnen kan zijn. Uitgangspunt voor het samenhangend beeld is het onderscheid in vijf aspecten van het ontwikkelwerk (Bemelmans 1991). Respectievelijk betreft het de aspecten modelleren, beheersen, leren, veranderen en balanceren. Modelleren en beheersen hebben met name betrekking op de informatiekundige en -technologische kant van het ontwikkelwerk. In de ontwikkelaspecten leren en veranderen staan menskundige, sociale en organisatiekundige zaken centraal. Balanceren heeft betrekking op het maken van afwegingen. De samenhang en interactie tussen de verschillende ontwikkelaspecten is verduidelijkt aan de hand van een aantal 'trade-off' -voorbeelden. Het ontwikkelaspectenmodel van hoofdstuk 3 dient in hoofdstuk 4 als kader om de verschillende soorten kwaliteitsopvattingen te ordenen en nader te beschrijven. Drie soorten 135

Nabeschouwing kwaliteitsopvattingen worden onderscheiden. De eerste opvatting van kwaliteit is dat kwaliteit wordt bewerkstelligd door een verzameling kenmerken in een produkt in te bouwen (zie onder andere (Boehm et al 1978)). Deze opvatting is sterk verwant met het ontwikkelaspect modelleren. De tweede opvatting is dat kwaliteit wordt bewerkstelligd door voorschriften en procedures te hanteren voor het ontwikkelproces (ISO 9000-3 1991). Deze opvatting is verwant met het ontwikkelaspect beheersen. In de derde opvatting, Total Quality Management genoemd, wordt gestreefd naar een geïntegreerde benadering van kwaliteit. Naast produkt- en procesaspecten spelen menskundige aspecten een rol. Kwaliteit wordt volgens deze opvatting met name bewerkstelligd door in samenwerkingsverbanden te streven naar continue verbetering (zie onder andere (Oakland 1989)). Deze drie soorten opvattingen worden nader beschreven vanuit de invalshoeken van respectievelijk het Wat (lees: het object van kwaliteit), het Door Wie (lees: het perspectief op kwaliteit) en het Hoe (lees: de wijze waarop met kwaliteit omgegaan). Samengevat zijn de belangrijkste resultaten van deze ordening: het object van kwaliteit verschilt per soort opvatting. Afwisselend ligt het accent op produkt-, proces-, en middelenkwaliteit Produktkwaliteit krijgt vooralsnog in de literatuur de meeste aandacht; kwaliteit dient vanuit minstens twee perspectieven te worden beschouwd, namelijk het perspectief van makers en het perspectief van afnemers; kwaliteit bewerkstelligen is tot nu toe voornamelijk een zaak van makers geweest. In de verschillende kwaliteitsopvattingen zijn het telkens de makers die bepalen welke maatregelen moeten worden genomen om kwaliteit te bewerkstelligen. Op grond van voorgaande resultaten wordt het begrip kwaliteit in deel drie van dit boek (de hoofdstukken 5, 6 en 7) verder uitgewerkt Het eerste deel van hoofdstuk 5 laat zien dat de betekenis van kwaliteit samenhangt met het soort produkt dat wordt ontwikkeld. Produkten laten zich karakteHseren op drie dimensies, respectievelijk de dimensie van de scope, de dimensie van de toestanden en de dimensie van de uniekheid van een produkt. Aangetoond wordt dat de betekenis van produktkwaliteit gradueel verschuift binnen elk van deze dimensies. Vervolgens laat hoofdstuk 5 de bruikbaarheid zien van de drie produktdimensies voor het specificeren van kwaliteitseisen. In hoofdstuk 6 wordt ingegaan op de betekenis van proces- en middelenkwaliteit Procesen middelenkwaliteit is vooralsnog een relatief onontgonnen gebied in de informatiesystemenwereld. Daarom geldt hier als uitgangspunt het adagium 'eerst weten voordat kan worden gemeten'. Onderscheid wordt gemaakt tussen modelleer-, beheers-, leer-, verander-, en balanceerprocessen. Met (Bush en Fenton 1990) wordt gesteld dat kwaliteit van processen en middelen geconcretiseerd dient te worden aan de hand van proceseigenschappen. V oor het bespreken van proceseigenschappen wordt gebruikt gemaakt van het groeimodel volgens (Humphrey 1989). Beschreven wordt dat de 136

Hoofdstuk 8

proceseigenschappen definieerbaarbeid en herhaalbaarheid van toepassing zijn op het modelleerwerk. De proceseigenschappen controleerbaarheid en bestuurbaarheid hebben met name betrekking op het beheersen. Veranderbaarbeid en verbeterbaarbeid zijn proceseigenschappen die betrekking hebben op leren en veranderen. Gesteld wordt dat proceskwaliteit inhoudt dat een goede beschrijving van het inhoudelijke modelleren noodzakelijk is. Dit is een voorwaarde om vervolgens te kunnen komen tot een bestuurbaar en controleerbaar (lees: beheersbaar) proces. Eerst daarna kan gestreefd worden naar een verbeterbaar (lees: leer- en veranderbaar) proces. Vetder wordt in hoofdstuk 6 aandacht besteed aan middelenkwaliteit Onderscheid wordt gemaakt tussen personele middelen en methoden. Ook hier geldt als uitgangspunt dat de verschillende middelen eerst beter omschreven moeten worden voordat kwaliteit bespreekbaar wordt. Evenals in de hoofdstukken 5 en 6 wordt ook hier het ontwikkelaspectenmodel gebruikt om de verschillende typen personele middelen en methoden te positioneren en nader te beschrijven. Zowel in de huidige functie- en taakbeschrijvingen (NGI 1993) van personele middelen als in de huidige methoden worden enkele beperkingen gesignaleerd. Hoofdstuk 7 is gericht op een werkwijze voor het specificeren \lan kwaliteitseisen. Gebruik wordt gemaakt van een aanpak die in de industriële produktie de laatste jaren meer en meer in de belangstelling staat, namelijk de methode Quality Function Deptoyment (QFD), (Hauser en Clausing 1988). Centraal staat in QFD een relatiematrix, het 'kwaliteitshuis' genoemd, waarin wensen en behoeften van klanten worden gerelateerd aan specificaties van een produkt. Dit concept is overgenomen voor het specificeren van kwaliteitseisen bij het ontwikkelen van informatiesystemen. Kwaliteitseisen van afnemers worden afgeleid uit de karakteristieken van een bedrijfssituatie van een te ontwikkelen systeem. In dit boek staat bij het afleiden en specificeren van kwaliteitseisen de communicatie tussen afnemers en makers centraal. Ten behoeve van de ondersteuning van die communicatie is een checklist ontwikkeld op basis van onder andere (Bemelmans 1986) en (Heemstra, Kusters, Tierolfen Trienekens 1993, 1994). Vervolgens wordt met behulp van twee relatiematrices aangegeven op welke wijze de bedrijfssituatiekarakteristieken samenhangen met de kwaliteitseisen. Tezamen met de functionele specificaties vormen de kwaliteitseisen het uitgangspunt voor het ontwerpen en bouwen van een informatiesysteem of softwareprodukt. Doel is dat door het expliciet maken van kwaliteitseisen in een samenwerkingsproces tussen afnemers en makers een informatiesysteem of softwareprodukt tot stand komt dat daadwerkelijk kwaliteit heeft.

8.2 Aanbevelingen Tijdens het ordenende werk in dit boek en de ontwikkeling van een methode voor het specificeren van kwaliteitseisen is een aantal probleemgebieden geïdentificeerd en zijn onderwerpen aangesneden waarop niet verder kon worden ingegaan omdat zij buiten de scope van dit boek vielen. Een aantal van deze probleemgebieden vormt onderzoeksgebieden op zich. In deze paragraaf beschrijven we vijf aanbevelingen voor verder onderzoek op deze gebieden. 137

Nabeschouwing Aanbeveling 1: integreer het specificeren van kwaliteitseisen in gangbare methoden en technieken Het specificeren van kwaliteitseisen is een onderbelicht gebied bij het ontwikkelen van infonnatiesystemen. Kwaliteitseisen bepalen echter in belangrijke mate het succes en de acceptatie van een infonnatiesysteem. Het specificeren van kwaliteitseisen kan uiteraard niet los worden gezien van het specificeren van functionele eisen. Het verdient daarom aanbeveling de in dit boek ontwikkelde methode verder uit te werken en te integreren in gangbare methoden, technieken en tools voor systeemontwikkeling. Het gaat hier met name om dié middelen en gereedschappen die toegepast worden in de eerste fasen van het ontwikkelwerk (c.q.: vooronderzoek, definitiestudie, basisontwerp en detailontwerp).

Aanbeveling 2: valideer de methode voor het specificeren van kwaliteitseisen Hoewel de beschreven methode voor het specificeren van kwaliteitseisen voor een belangrijk deel is ontwikkeld in het kader van contractresearch in de praktijk heeft uitvoerige toetsing nog niet plaatsgevonden. Het specificeren van kwaliteitseisen is een proces dat zich vooralsnog in de eerste fasen van het groeimodel van Humphrey bevindt. Dat wil zeggen dat alleen proceseigenschappen als definieerbaarbeid en herhaalbaarheid erop van toepassing zijn. Om te komen tot een beheersbaar proces, met als proceseigenschap bijvoorbeeld controleerbaarheid, is registratie van resultaten, toetsing en validatie van de methode in de praktijk noodzakelijk. Volgroeidbeid van de methode kan worden bereikt door continue verbetering na te streven. Dit houdt in dat de methode periodiek moet worden verbeterd op grond van vastgelegde ervaringen.

Aanbeveling 3: werk de methode uit voor andere toepassingsgebieden Dit boek richt zich met name op het toepassingsgebied van de bestuurlijke en administratieve infonnatiesystemen. Gezien het snel toenemende belang van 'embedded software' wordt aanbevolen de methode uit te werken voor dit toepassingsgebied.

Aanbeveling 4: concretiseer proces- en middelenkwaliteit In de literatuur staan kwaliteitseisen van infonnatiesystemen en softwareprodokten centraal. Dit betekent dat de aandacht vooral uit gaat naar de kwaliteit van prodokten van het ontwikkelwerk. Vooralsnog is in literatuur en praktijk weinig aandacht besteed aan de kwaliteitsbepalende eigenschappen of kenmerken van processen en middelen (onder andere geautomatiseerde gereedschappen zoals CASE-tools). In dit boek is daartoe een eerste aanzet gedaan. Het verdient aanbeveling deze aanzet verder uit te werken en te detailleren zodat ook de bespreekbaarbeid en hanteerbaarheid van proces- en middelenkwaliteit verder kan toenemen. 138

Hoofdstuk 8 Aanbeveling 5: verduidelijk de rol van balanceren binnen integrale kwaliteitszorg van het ontwikkelen van injonnatiesystemen

De drie verschillende soorten kwaliteitsopvattingen zoals beschreven in dit boek zijn verwant met respectievelijk de ontwikkelaspecten modelleren, beheersen, en leren en veranderen. Binnen een samenhangend beeld van systeemontwikkeling, met als verbindend element balanceren, vullen zij elkaar aan. Dit model kan als basis worden beschouwd voor het opzetten van integrale kwaliteitszorg. Teneinde integrale kwaliteitszorg bij systeemontwikkeling te realiseren dienen afwegingen te worden gemaakt tussen kwaliteitseisen (modelleren), te hanteren procedures en richtlijnen (beheersen) en te organiseren samenwerking tussen betrokkenen om continue verbetering na te streven (leren en veranderen). Het verdient aanbeveling de betekenis van balanceren bij integrale kwaliteitszorg nader te onderzoeken. Eindconclusie Dit boek gaat over kwaliteit van informatiesystemen en informatiesysteemontwikkeling. In de eerste vier hoofdstukken staat centraal het inventariseren en ordenen van kwaliteitsopvattingen. Hoofddoel is de bespreekbaarbeid en hanteerbaarheid van kwaliteit te verbeteren. Onder meer is duidelijk geworden dat voor een zinvol gebruik van het begrip kwaliteit altijd eerst dient te worden vastgesteld wat het object is van kwaliteit. Objecten worden onderverdeeld in drie klassen, respectievelijk de klasse van produkten, van processen en van middelen (zowel mensen als methoden, technieken en tools). In de hoofdstukken 5, 6 en 7 wordt nader ingegaan op het omgaan met kwaliteit binnen elk van de drie klassen van produkten, processen en middelen. Concretisering van procesen middelenkwaliteit is in hoofdstuk 6 toegespitst op het beschrijven van voorschriften voor het verrichten van ontwikkelactiviteiten. Voorschriften verschillen met het type produkt en het type ontwikkelactiviteit. Omgaan met softwareproduktkwaliteit is in de hoofdstukken 5 en 7 toegespitst op de ontwikkeling van een methode voor het specificeren van kwaliteitseisen. Een variant van deze methode is reeds gevalideerd in een praktijksituatie. Ook de resultaten daarvan vragen om verdere toetsing en evaluatie van de methode in de praktijk.

139

Summary

This hook focuses on the concept of quality in the infonnation systems domain. The hook bas two main objectives. The flrst main objective is to classify and to discuss the different interpretations of quality. The second objective is to improve the applicability of the concept of quality. An approach is developed and steps are made towards a method for the identiflcation and the specmcation of software quality factors. This hook is, divided in three parts. The first part (chapter 1 and 2) starts with an introduetion into the growing importance of quality in the area of infonnation systems. For many years the software industry has focused on functional design aspects of software applications and on control aspects (i.e. time and costs) of software development projects. Recently the 1990s have been depicted as the software quality era. User.s of infonnation systems are becoming increasingly demanding and they are pushing quality to the forefront of their wishes and requirements. However, until now quality has different and sometimes confusing meanings. As a consequence it is very difficult, both for software users and for software producers, to detennine if a 'quality job' was done (after the execution of a project), and if a delivered or implemented infonnation system is indeed a 'quality product'. Chapter 2 discusses results of an empirical study on the probieros and the needs of software producing organisations in the Netherlands. One of the main results is that practitioners are currently more interested in a stepwise improvement of existing approaches and methods then in the development of complete new methods, techniques and tools. The second part of this hook (chapter.s 3 and 4) presents an integrated model of infonnation systems development aspects. The objective of this model is to serve as a framework for the discussion of the different interpretations of the concept of quality. Main elements of the integrated model are the flve aspects of infonnation systems development (Bemelmans 1991). They are respectively called the modelling, the controlling, the learning, the changing and the balancing aspect. The balancing aspect reflects the importance of trade-off decisions in infonnation systems development. In the integrated model the balancing aspect interconnects the other development aspects. In chapter 4 three types of interpretations of the concept of quality are distinguished. They are respectively described as the product view on quality, the process view on quality and the integrated view on quality. The product view reflects the idea that software quality can be gained by imptementing a set of attributes into a software product. The process view says that software quality can be assured by the development of procedures that guide the analyses and design activities. The integrated view reflects the idea that quality bas to be derived by an integral set of improvement activities. In the latter human resource factors and teamwork concepts play an important role. The three types of interpretations of quality are described more in depth by focusing on respectively the What, the By Whom and the How. Some major results are: to achleve quality in software production a distinction has to be made between software product-, software process- and software resource quality; software quality can be considered from different per.spectives. Main per.spectives are the perspective of software producers and the per.spective of software user.s;

140

users or clients are hardly involved in the identi.fication and the specification of software quality factors.

In part three of this book (chapters 5, 6 and 7) the concept of quality is elaborated further. Chapter 5 shows that the meaning of software product quality depends on the type of the software product that has to be developed. Software products can be characterised on three dimensions, respectively the dimension of the scope, the dimension of the life cycle phases of which a developer is responsible for, and the dimension of the uniqueness of a product Consequendy the applicability of the three software product dimensions is discussed by differentiating a set of software quality factors. 1be differentiation shows the relations between the importance of software quality factors and the characteristics of software products. Chapter 6 discusses the meaning of process and resource quality. Process and resource quality is until now a relatively undeveloped area in the information systems industry. Therefore we introduce the adagium 'knowing before measuring'. The development activities modelling, controlling, learning and changing differ with the type of software product that is being developed. These differences, and their consequences for the way the software processes are executed, are described. Chapter 6 also discusses resource quality. A distinction is made between personal resources and non-personal resources, such as methods and techniques. Chapter 7 focuses on the development of a method for the identification and the specification of software quality factors. The Process-Control-Information (PCI}-model of (Bemelmans 1986) is used to derive a questionnaire to communicate with users about the characteristics of their business situations. The results of this communication process can be related to software quality factors by means of two different but complementary relation matrices. Together with the functional specifications of a software product the software quality factors are the basis for the design of an information system. The book fmishes with five recommendations for forther research (chapter 8). First, the specification of software quality factors is a relatively unexplored area in the field of information systems development. However, it is clear that quality factors determine to a great extent the success and the acceptation of an information system. It is evident that the specification of software quality factors can't be separated from the specification of functional requirements. Therefore we recommend the integration of the developed method in this book with existing specification methods, techniques and tools. Second, although the method for the specification of software quality factors has been developed in research projects in practice, it has not yet been validated extensively. Therefore the determination and specification of software quality factors can be considered as a process in the first phases of the maturity model (Humphrey 1989). This means that this process is only to some extent defmable and repeatable. To reach the higher level maturity stages 'manageable' and 'optimizing', registration of the results of application and validadon of the method in different business situations is necessary. This means that the method should be enriched and improved periodically on the basis of experiences of previous applications.

141

SumnuJry

Third, this book is restricted to the application area of business infonnation systems. It is recommended to validate and to elaborate the developed metbod for other application areas, such as the area of embedded software systems. Fourth, literature about software quality emphasizes product quality factors. Until now, both in literature and in practice, little attention has been given to the quality factors of processes and resources. This book made a ftrst step by descrihing types ~f processes and types of resources. It is recommended to elaborate this ftrst step to increase the applicability of the concepts of process and resource quality. Fijth, the different interpretations of the concept of quality, i.e. the product view, the process view and the integrated view are complementary. Their differences and their interrelations can be discussed by using a framework of development aspects. The central element in this framework is the aspect of balancing. It is recommended to continue research on the importance of balancing with respect to the development and implementation of integrated software quality assurance systems in organisations.

142

Literatuur Aerts A.T.M., G. Alb1as, K.M. van Hee, Conceptueel modelleren van informatiesystemen, Academie Service, 1991. Arge1o S.M., A.J.J. van Rie1, J.J.V.R. Wintraecken, Wegwijs in het oerwoud van methoden, technieken en hulpmiddelen, Infonnatie, jrg. 32, nr. 2, 1990. Argyris C., Reasoning, Learning and Action, Jossey-Bass Publishers, 1982. Avison D., A. Wood-Harper, Multiview, An exploration in information systems development, B1ackwell Scientific Publications, 1990. Azuma U. et al, Evaluation of Software Quality, Instac Research Report, Tokyo, 1991. Bailey J.E., S.W. Pearson, Development of a tooi for measuring and analyzing computer user satisfaction, Management Science, Vol. 29, Nr. 6, 1983. Basili V.R., H.O. Rombach, The Tame Project: Towards impravement oriented software environments, IEEE Transactions on Software Engineering, Vol. 14, nr. 6, 1988. Basili V.R., J.D. Musa, The future engineering of software: a management perspective, IEEE Computer, Vol. 24, Nr. 9, 1991. Basili V.R., R.W. Se1by, Paradigms for Experimentation and Empirica/ Studies in Software Engineering, in: B. Littlewood and D. Milier (eds.), Reliability Engineering and System Safety. E1sevier Science Publishers Ltd, London, 1991. Basili V.R., Applying The GoaVQuestion/Metric Paradigm In The Experience Factory, in: Proceedings of the Tenth Annual Conference on Application of Software Metrics and Quality Assurance in Industry, Centre for Software Reliability, 1993. Bemelmans T.M.A., Bedrijfskundig Ontwerpen van Bestuurlijke Informatiesystemen, in: P.A. Comelis, J.M. van Oorschot (eds.), Automatisering met een menselijk gezicht, Kluwer, 1986. Bemelmans T.M.A., Invoering Case tools, een langdurig en kostenintensief proces, CA techniek in bedrijf, jrg. 8, nr. 5, VNU, 1990. Bemelmans T.M.A., Bestuurlijke Informatiesystemen en Automatisering, Stenfert Kroese B.V., 4e druk, 1991. Berg van den R.J., J.J.M. Trienekens, Setting Priorities in Software Product Quality; towards a CASE based instrument, in: Proceedings van de Sixth workshop on CASE: Software lmprovement with Case, Singapore, Singapore, 1993.

143

Literatuur Bergstra J.A., G.R. Renardel de Lavalette, De plaats van formele specificaties in de softwaretechnologie, Infonnatie, jrg. 31, nr. 6, 1989. Biggerstaft T.J., A.J. Perlis, Software Reusability, VoL 1: Concepts and Models, Vol. 2 Applications and Experience, Addison-Wesley, 1989. Blauw J.N., Dosterhoorn A., Quality Function Deployment, de regelk;aart voor het ontwerpproces, in: Proceedings Congres Kwaliteit In De Ontwerpfase, Stichting Bedrijfskunde Congres Industria, 1992. Boddendijk H.G., Kwaliteit in Onderwijs, Onderwijs in Kwaliteit, Intreerede, Technische Universiteit Eindhoven, 1992. Boehm B.W. et al, Characteristics of Software Quality, TRW Series of Software Technology, Vol. 1, North Holland Publishing Company, 1978. Boehm B.W., A Spiral Model of Software Development and Enhancement, IEEE Computer, Vol. 21, Nr. 5, 1988. Bossert, J.L., Quality Function Deployment, a practitioners approach, Marcel Dekker, Inc., 1991. Bush M.E., N.E. Fenton, Software Measurement: A Conceptual Framework, Joumal of Systems Software, Vol. 12, nr. 3, 1990. Card D.N., R.L. Glass, Measuring Software Design Quality, Prentice-Hall, 1990. Cavano J.P., J.A. McCall, A framework for the measurement of software quality, Proceedings of the Software Quality and Assurance workshop, red. S. Jackson en J. Lockett, ACM, 1978. 1

Crosby P.B., Quality is Free, the art ofmaking quality certain, McGraw-Hill, 1979. Davis G.B., Olson M.H., Management lnformation Systems, McGraw-Hill 1984. Delen G.P.A.J., D.B.B. Rijsenbrij, Kwaliteitsattributen van automatiseringsprojecten en informatiesystemen, Infonnatie, jrg. 32, nr. l, 1990a. Delen G.P.A.J., D.B.B. Rijsenbrij, Het 'realiseren' en 'meten' van produktkwaliteit, Infonnatie, jrg. 32, nr. 11, 1990b. Delen G.P.A.J., H.J. Kouwenhoven, D.B.B. Rijsenbrij, Kwaliteit van Produkten, Cap Gemini Publishing, Rijswijk, 1991. Deming W .E., Out of the Crisis, MIT Center for Advaneed Engineering Study, 1986. 144

Deutsch M.S., R.S. Willis, Software Quality Engineering, a Total Technica/ and Management Approach, Prentice-Hall, 1987. Dietz J., ModeUeren en Specificeren van Informatiesystemen, Academisch Proefschrift Technische Universiteit Eindhoven, 1987. Evans M.W., J.J. Marciniak, Software Quality Assurance & Management, John Wiley & Sons, 1987. Fagan M., Advances in Software Inspections, IEEE Transactions on Software Engineering, Vol. 12, Nr. 7, 1986. Fenton N., A. Melton, Deriving structurally based software measures, Joumal of Systems Software, Vol. 15, nr. 12, 1990. Fenton N.E., Software Metrics, A Rigarous Approach, Chapman & Hall, 1991. Garvin O.A., What does product quality really mean ?, Sloan Management Review, Vol. 26, nr. 1, 1984. Garvin O.A., Managing Quality, The Free Press, Macmillan lnc., 1988. Genuchten van M.J.I.M., Towards a Software Factory, Academisch Proefschrift Technische Universiteit Eindhoven, 1991. Genuchten van M.J.I.M, T.M.A. Bemelmans, F.J. Heemstra, De Software-fabriek, Informatie, Jrg. 35, Nr. 4, 1993. Gilb T., Principlesof Software Engineering Management, Addison-Wesley, 1988. Gillies A.C., Software Quality, theory and management, Chapman & Hall, 1992. Glass R.L., The Best and Worst of Software in the I980s, Joumal of Systems Software, Vol. 17, Nr. 2, 1992. Greveling N.G., Injormatieplanstudie, Model voor Informatiestrategie en Informatieplan, Academie Service, 1990. Griethuijzen van J.J., O.A. Jardine, Infomod, een samenvatting, Academie Service, 1987. Haas de R.J., C.S.M. Wubbels, Situationeel projectmanagement bij automatisering, Informatie, jrg. 32, nr. 2, 1990. Hauser J.R., 0. Clausing, The House of Quality, Harvard Business Review, Vol. 66, Nr. 3,

1988. 145

Literatuur Heemstra F.J., Hoe duur is programmatuur? Begroten en beheersen van softwareontwikkeling, Kluwer, 1989. Heemstra F.J., R.J. Kusters, J.J.M. Trienekens, Dejining Systems Quality: involving endusers, in Proceedings van de European Function Point User Group Co~erence, Bristol, Engeland, 1993. Heemstra F.J., R.J. Kusters, J.W. Tierolf, J.J.M. Trienekens, Het specificeren van informatiesysteemkwaliteit door communicatie met eindgebruikers, in: Procbedings van de jaarlijkse conferentie van de Nederlandse Organisatie voor Bedrijfskundig Onderzoek (NOBO), Rotterdam, 1993. Heemstra F.J., R.J. Kusters, J.W. Tierolf, J.J.M. Trienekens, Communiceren over kwaliteit, Lansa Pub1ishing, 1994. Hirschheim R., H.K. Klein, Four Paradigms of lnjormation Systems Development, Communications of the ACM, Vol. 32, Nr. 10, 1989. Humphrey W.S., Managing the software process, Addison-Wesley, 1989. IEEE Quality Metrics Standards Committee, Standards for Software Quality Assurance Plans, Std 730, 1984. IEEE Quality Metrics Standards Committee, A standard for software quality metrics, Pl061, 1986. llvari J., Levels of Abstraction as a Conceptual Framework for an lnformat,ion System, in: Fatkenberg E.D., P. Lindgreen, Information System Concepts: An In-depth Analysis, Proceedings van de IFIP TC 8/WG 8.1 Working Conference on Infoqnation System Concepts, North-Holland, 1989. lshikawa, K., What is Total Quality Control? The Japanese Way, Prentice Hall, 1985. ISO 8402, Quality Vocabulary, International Organization for Standardization, 1987. ISO 9000, Quality management and quality assurance standards - Guidelines for selection and use, International Organization of Standardization, 1987. ISO 9000-3, Quality management and quality assurance standards, Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenace of software, International Organization for Standardization, 1991. Quality ISOIIEC 9126, lnformation Technology - Software Product Evaluation characteristics and guidelines for their use, International Organization for Standardization, 1991.

146

Ives B., M.H. Olson, J.J. Baroudi, The Measurement of User Information Satisfaction, Communications of the ACM, Volume 26, Nr. 10, 1983. Jarke M., K. Pohl, Information Systems Quality and Quality Information Systems, in: Kendal1, Lyytinen, DeGross (eds.), Proceedings of the IFIP 8.2 Working Conference on The Impact of Computer Supported Technologies on Infonnation Systems Deve1opment, Minnesota. USA, 1992. Juran J.M., Quality Control Handbook, McGraw-Hill, 1979. Kaposi A., B. Kitchenham, The architecture of system quality, Software Engineering Joumal, Vol. 2, nr. I, 1987. Kessel van P.L.A.M., Kwaliteit van de informatievooniening, een bedrijfskundig model, Informatie, jrg. 33, nr. 2, 1991.

Kim K.K., User Injormation Satisfaction: Towards Conceptual Clarity, in: Proceedings van de Eleventh International Conference on Information Systems, J.l. DeGross, M. Alavi, H. Oppeland (eds.), Kopenhagen, Denemarken, ACM, 1990. Krooshof R.L. et al, Guide to Project Management- PRODOSTA, N.V. Philips Eindhoven, Eindhoven, 1987. Kusters R.J., G.M. Wijers et al, Het gebruik van CASE-tools in Nederland, Kluwer Bedrijfswetenschappen, 1992. Langefors B., Information Systems, In: lnformation Processing 1974, North-Holland, Amsterdam, 1974. Leeuw de A.C.J., Organisaties: Management, Analyse, Ontwerp en Verandering: een Systeemvisie, van Gorcum & Comp., 1986. Lindgreen P. (ed.), A Frameworkof Information System Concepts: Interim Rappon, IFIP WG 8.1 Task Group FRISCO, Nederland, 1990. Looijen M., EBM- Een BeheerMethodiek, Lansa Publishing, 1993. Lundeberg M., G. Go1dkuhl, A. Nilsson, Systeemontwikkeling volgens ISAC, de ISACMethodiek, Samsom, 1982.

Martin J., Information Engineering Volume 1: Introduetion to Information engineering, Savant Research Studies, 1986. McFarlan, F.W., Portfolio Approach to Information Systems, Harvard Business Review, Vol. 59, nr. 5, 1981. 147

Literatuur Mumford E., Designing Human Systems for New Technology, The ETillCS Method, Manchester Business School, 1983. NOl, Functies in de informatica, Werkgroep Functie-ordening van het Nederlands Genootschap voor Informatica, 1986. NOl, Taken en functies in de bestuurlijke informatica, een voorstel tot ordening, Werkgroep Functies Bestuurlijke Informatica van de Commissie Beroepsontwikkeling van het Nederlands Genootschap voor Informatica, 1993. Norman R.J., G. Forte, Case in the '90s, Communications of the ACM, Vol. 35, Nr. 4, 1992. Oakland J.S., Total Quality Management, in: Proceedings of the Second International Conference on Total Quality Management, Cotswold Press Ltd., 1989. Olie T.W. et al, lnformation Systems Methodologies, A Framework for Understanding, Addison-Wesley, 1988. Pfleeger S.L., Setting Up A Metrics Program In lndustry, in: Proceedings van de Tenth Annual Conference on Application of Software Metrics and Quality Assurance in Industry, Centre for Software Reliability, 1993. Philips International B.V., Corporate Quality Bureau, Philips Quality, 1993. Putnam L., Software costing estimating and life cycle control, IEEE Computer Society Press, 1980. Rees van J.R., De methode doet het niet, in: NOl-rapport Methodieken voor lnformatiesysteemontwikkeling, nr. 3A, 1984. Rienstra F., Kwaliteitssystemen: normen, evaluatie en certificatie, Informatie, jrg. 33, nr. 9, 1991. Rijsenbrij D.B.B, Kwaliteit in Informatie, Informatie, jrg. 35, nr. I, 1993. Schaick van E.A., A Management System for the lnformation Business: Organizational Analysis, Prentice-Hall, 1985. Schnelle W., I. Stolz,lnteractional Leaming, Metaplan, Quickbom, 1977. Serc-Quint, Het specificeren van software-kwaliteit, een praktische handleiding, Kluwer Bedrijfswetenschappen, 1992. Simon, H.A., The New Science of Management Decision, Harpers and Brothers, 1960. 148

Stobart S.C., A.J. van Reeken, O.C. Low, JJ.M. Trienekens, J.O. Jenkins, J.B. Thompson, An Empirica/ Evaluation of the Use of CASE tools, in: Proceedings van The Sixth Conference on CASE: Software Improvement with CASE, Singapore, Singapore, 1993. Straus A., J. Corbin, Basicsof Qualitative Research, Sage Publications, 1991. Strausz I., De kwaliteit van software, Informatie, jrg. 25, nr. 12, 1983. TickiT, Guide to Software Quality Management Systems, Construction and Certijication using EN 29001, TickiT Office, London, 1991. Trienekens J.J.M., R.J. Kusters, Computer Based Support in Software Production Environments, in: Proceedings van de SION-Conferentie Computing Science in The Netherlands (CSN '91), J. van Leeuwen (ed.), Stichting Mathematisch Centrum, 1991. Trienekens J.J.M. en R.J. Kusters, Customer Orientation as a Basis for Computer Supported Technologies in Software Production, in: K.E. Kendall, K. Lyytinen (eds.), Proceedings van de IFIP 8.2 Working Conference on The Impact of Computer Supported Technologies on Information Systems Development, North-Holland, 1992. Trienekens J.J.M., Quality Management in Software Production, A Customer Oriented Approach, in: Proceedings van de IFIP 5.7 Working Conference on lntegration in Production Management, H.J. Pels en J.C. Wortmann (eds.), Nederland, North-Holland, 1992. Trienekens J.J.M., A.J. van Reeken, What determines the Ef!ectiveness of CASE tools? Answers suggested by Empirical Research, in: Proceedings van de Fifth International Workshop on Computer-Aided Software Engineering, G. Forte, N.H. Madhavji, H. A. Müller (eds.), IEEE Computer Society Press, Montreal, Canada, 1992. Trienekens J.J.M., P. Thoma, Production Characteristics as a Bases for Ef!ective Quality Systems, leaming form industrial manufacturing, in: Proceedings van de Second International Conference on Software Quality Management (SQM'94), (wordt gepubliceerd door Computational Mechanics Publications, UK), Edinburgh, Schotland, 1994. Turner W.S., R.P. Langerb.orst, G.F. Hice, H.B. Eilers, A.A. Uijttenbroek, System Development Methodology (Nederlandse vertaling), Cap Gemini!Pandata, 1989. Vincent J., A. Waters, J. Sinclair, Software Quality Assurance, Vol 1: Practice and Experience, Prentice-Hall, 1988. Vliet J.C. van, Software engineering, Principles and Practice, John Wiley & Sons, 1993. Vonk R., Prototyping of lnformation Systems (in Dutch), Academie Service, 1987.

149

Literatuur Wijers G.M., H.E. van Dort, Ervaringen met het gebruik van CASE-tools, Informatie, jrg. 32, nr. 10, 1990. Wijnen G., W. Renes, P. Stonn, Projectmatig Werken, Het Spectrum B.V., 1987. Willmer H., Systematic software quality control using quality and product models, Springer Verlag, 1985. Willmot H., B. Elkjaer, System developers: preoccupations, knowledge, and power, in: Proceedings of the Eleventh International Conference on Infonnation Systems, J.I. DeGross, M. Alavi, H. Oppeland (eds.), Kopenhagen, Denemarken, 1990. Wintmeeken J.J.V.R., Informatie-analyse volgens NIAM, Academie Service, 1987. Yourdon E., Structured Walkthroughs, Yourdon Press, 1985. Yourdon E., Modem Structured Analysis, Yourdon Press, 1989. Zachman J.A., A framework for in/ormation systems architecture, IBM Systems Journal, vol. 26, nr. 3, 1987. Zijlker A.W., Informatie Technologie en de twee-bij-twee matrix, Infonnatie, jrg. 29, nr. 10, 1987.

150

Index a

afnemer

b

balanceren balanceren intern balanceren extern beheersen beheersfuncties beheersmethoden

53, 112 4 44 46

40 102 103 m

conceptstructuur contingentie contingentietheorie

73 20

d

data-aspect

38

e

eigenschappen (van een produkt) empirisch onderzoek evolutionair ontwikkelen

c

g

k

71

kwaliteits 'rating'

34

70, 112 20, 134 25

groeistadia gedragsaspect

29 38

ISO 9000-3 ISO 9000

55 17

integrale (kwaliteits) opvatting indicator

58 73

karakteristieken van een te besturen proces 123 kwaliteitsatribuut 71 kwaliteitsbehoefte 112 kwaliteitscriterium 71 kwaliteitsdefmities 12 kwaliteitseisen 3, 53, 85 kwaliteitsfactor 70, 71 kwaliteitshuis 120 kwaliteitskringloop voor het specificeren 118 kwaliteitskringloop voor het realiseren 113 kwaliteitsmetriek 70,71 kwaliteitsopvattingen 50 kwaliteitsprotiel 71

leren en veranderen leer- en veranderfuncties leer- en verandermethoden lineaire ontwikkelstrategie

41 106 107

73, maatregelen 60, maker meetschaal meetvoorschrift methoden methodologie middelenattributen 93, 97. 102, middelenkwaliteit modelleerfuncties modelleermethoden modelleren moeilijkheidsgraad van de 122, besturing

113 112 73 73 35 34 66 107 97 98 36

25

124

94, 97, 102, 106

n

NGI

0

objecten van kwaliteit ontwikkelaspecten ontwikkelscholen

p

111, 121 PBI procesaspect 38 procesattributen 66 proceseigenschappen 92 92,95, 99,104 proceskwaliteit proceskwaliteitsopvatting 50 produktattributen 64 produktdimensies 75 produktkarakteristieken 84 produktkwaliteit 64 produktkwaliteitsopvatting 50 prototyping 25

q

QFD

r

realiseren relatiematrix

59,61 27,36 35

119 37, 112 115, 120, 125, 129 151

lrulex s

scope van een produkt situatiekarakteristieken specificeren van kwaliteitseisen specifiek infonnatiesysteem standaard infonnatiesysteem strategieën voor infonnatie~ behoeftebepaling strategieën voor systeemontwikkeling systeemontwikkelfasen systeemontwikkelaspecten

75 118 112 81 82 117 27 24

6

t

78 toestanden van een produkt 17, 41, 58 TQM

u

uniekheid van een produkt

80

V

veranderingsbereidheid

28

w

waarderingsindicator

71

152

Curriculum vitae Josephus Jacobus Maria Trienekens werd geboren op 19 juli 1952 in Breda. Na de Rijks Hogere Burger School in Venlo te hebben doorlopen studeerde hij Civiele Techniek aan de Technische Universiteit Delft. Het ingenieursdiploma behaalde hij in 1980. Tot 1983 was hij als docent wiskunde en natuurkunde werkzaam in het voorbereidend wetenschappelijk onderwijs. In deze tijd was hij voorzitter van de Stichting Eye-Train in Venlo. Deze stichting richtte zich op de ontwikkeling van voorlichtingsmateriaal over automatisering in het bedrijfsleven voor het voorbereidend wetenschappelijk onderwijs en het hoger beroepsonderwijs. Van 1983 tot 1987 was hij als docent bedrijfsinformatica verbonden aan respectievelijk het Heao Zwolle en het Heao Sittard. In het laatste jaar van deze periode werkte hij als projectadviseur voltijds binnen de afdeling Organisatie & Automatisering van DSM Limburg in Heerlen. Vanaf 1987 is hij als universitair docent in dienst van de Technische Universiteit Eindhoven bij de Faculteit Technische Bedrijfskunde, vakgroep Informatie & Technologie. Hij publiceerde de afgelopen jaren enkele tientallen artikelen in wetenschappelijke tijdschriften en vakbladen. Hij is lid van IWCASE en 'friend' van IFIP 8.2. Naast zijn reguliere onderwijstaken organiseert hij verschillende postacademische opleidingen op het gebied van informatietechnologie. Hij heeft regelmatig de verantwoordelijkheid voor contractresearchprojecten in de (software)-industrie, de overheid en de zakelijke dienstverlening.

153

STELLINGEN behorende bij het proefschrift

Tijd voor kwaliteit werken aan betere informatiesystemen

van J os J .M. Trienekens Eindhoven, 15 april 1994

I

De grote aandacht die in de literatuur wordt besteed aan nieuwe methoden en technieken voor het specificeren van informatiesystemen staat in schril contrast met de grote behoefte in de praktijk aan stapsgewijze verbetering van bestaande werkwijzen. (Bronnen:

hoofdstukken 2 en 7 van dit proefschrift; Heemstra FJ., Kusters R.J., Tierolf J.W. en Trienekens JJ.M., Het specificeren van informatiesysteemkwaliteit door communicatie met eindgebruikers, Proceedings van de zesde onderzoekdag van de Nederlandse Organisatie voor Bedrijfskundig Onderzoek (NOBO), Rotterdam, november 1993).

II

Voordat kwaliteitsmetingen kunnen worden verricht dient eerst het object van kwaliteitsmeting te worden beschreven. Bij informatiesysteemontwikkeling gelden in dit kader drie soorten objecten, te weten produkten, processen en middelen. (Bronnen:

hoofdstuk 4 van dit proefschrift; Fenton N.E., Software Metrics, A Rigorous Approach, Chapman & Hall, 1991).

III

Verschilpunten en overeenkomsten tussen kwaliteitsopvattingen worden duidelijk bij beantwoording van de vragen: - op welke objecten richt een kwaliteitsopvatting zich ? - vanuit welk perspectief (door wie) wordt een kwaliteitsopvatting gehanteerd ? - hoe dient volgens de kwaliteitsopvatting kwaliteit te worden bepaald ? (Bronnen:

hoofdstuk 4 van dit proefschrift; Trienekens JJ.M., Quality management in software production, a customer oriented approach, Proceedings van de IFIP 5.7 Working Conference on Integration in Production Management, HJ. Pels en J.C. Wortmann (eds.), Eindhoven, augustus 1992).

IV

In elke ontwerpdiscipline moeten prioriteiten worden gesteld met betrekking tot produkteisen en te realiseren produktkenmerken. Positionering van een informatiesysteem in termen van scope, toestanden, en uniekheid van dat systeem leidt tot een betere prioriteitenafweging van kwaliteitseisen. (Bron:

honfdstuk 5 van dit proefschrift).

V

Negentig procent van de software-industrie bevindt zich voor wat betreft de mate van volgroeibeid in een initiële fase. Voordat een volgroeid stadium wordt bereikt dient het ontwikkelwerk beter te worden begrepen en gedefinieerd. Daarom geldt voor het merendeel van de software-industrie vooralsnog het adagium 'weet voordat je meet'. (Bro!Ulen:

hoofdstuk 6 van dit proefschrift; Humphrey W.S., Managing the software process, Addison-Wesley, 1989).

VI Kwaliteit zit in de mensen die het doen. Een eerste stap naar concretisering van kwaliteit van mensen kan worden gezet door taken en functies van bij het ontwikkelwerk betrokken personen te beschrijven, normen voor kennis- en ervaringsniveaus te definiëren en periodieke toetsingen aan die normen te verrichten. (Bro!Ulen:

hoofdstuk 6 van dit proefschrift; NOl-rapport, Taken en functies in de bestuurlijke informatica, 1993).

VII

Kwaliteitseisen zijn in tegenstelling tot functionele eisen meer generiek per bedrijfssituatie. Dit nodigt uit tot het expliciet vermelden van kwaliteitseisen in referentiemodellen. (Bro!Ulen:

Greveling NJ.W., Informatieplanstudie, Academie Service, 1991; Bemelmans T.M.A., Bestuurlijke Informatiesystemen en Automatisering, Stenfen Kroese, 1991).

VIII Het verzorgen van post-academisch onderwijs door wetenschappelijke medewerkers heeft een positieve invloed op de ontwikkeling van hun 'Fingerspitzengefühl' voor bedrijfskundige probleemstellingen.

IX

Door studenten in academische afstudeerprojecten ruimte te geven voor wetenschappelijke oriëntaties kunnen opstartproblemen van promotie-onderzoek worden verminderd.

x 'User based' kwaliteit van bedrijfskundige onderzoeksresultaten is pas aan de orde wanneer het onderzoek is gebaseerd op een concrete probleemstelling uit de praktijk, het onderzoek (deels) in de praktijk plaatsvindt en 'last but not least' wanneer de resultaten worden getoetst aan de praktijk.

XI De titel van dit boek 'Tijd voor Kwaliteit' verwoordt zowel de actualiteit van het onderwerp 'produktkwaliteit' als het feit dat het bewerkstelligen van kwaliteit tijd vraagt.

XII In tegenstelling tot de Civiele Techniek is de Bedrijfskundige Infonnatica nog niet zo volgroeid dat veel van haar produkten als kunstwerken kunnen worden betiteld.

XIII Waarover men niet spreken kan Daarover moet men spreken Want daarvan leeft de wetenschap En evolueert zij Vrij naar:

(bron) W. Luijpen, Nieuwe Inleiding tot de Existentiële Fenomenologie, Het Spectrum B.V. Utrecht/Antwerpen, 1973.