State of the Art rapport KC Kwaliteitszorg voor Systeemontwikkeling

Ministerie van Verkeer en Waterstaat

jklmnopq Adviesdienst Verkeer en Vervoer

State of the Art rapport KC Kwaliteitszorg voor Systeemontwikkeling 31 juli 2003

jklmnopq


Adviesdienst Verkeer en Vervoer

State of the Art rapport Kwaliteitszorg voor Systeemontwikkeling 31 juli 2003

Documentgegevens Afdeling ITS Ontwikkeling Contactpersoon Auteurs

Versie Datum

: Anke Sijtsema : Han Goei, Ronald v.d. Hengel, Gerald van Kampen, Hans van Knotsenburg, Rob Ramsteijn, Ernst Scheerder, Anke Sijtsema, Eric v.d. Ster, Johann Visser, Jacorien Wouters : 1.0 : 31 juli 2003

jklmnopq


Adviesdienst Verkeer en Vervoer

Aanpassingsoverzicht Versie

Status

Datum

Gereviseerd door

Reden

0.1

Werkdocument

0.161

Werkdocument 2002 1122

GvK

Eerste opgemaakte versie

0.17


JW / GvK

Samenvatting toegevoegd

0.173


ES / GvK

herziening H2, H3 & H4

0.18

Werkdocument

0.191


Initieel document

Bewerking tijdens KC-vergadering

0.194


GvK

Bevroren versie, voorlopige oplevering aan HAH

0.200


GvK

kopie van 0.194 in "nieuw document". Geen last meer van veranderde opmaak door het rapportmacro bij afdrukken.

0.202


GvK

auto-opmaak + nabewerking

0.203


GvK

Gecombineerd H2+H5 ingevoegd; oude H’s verwijderd

0.204


GvK

aantekeningen januari 2003 in H2 verwerkt; status document op 1 mei 2003

0.205

Werkdocument

GvK

0.206

Werkdocument

GvK

0.207


GvK

0.208


JoVi / GvK

aantekeningen januari 2003 in H3 verwerkt

Bijlage redactioneel bijgewerkt H5 “aanbevelingen” ingevoegd (nog niet inhoudelijk / redactioneel bekeken); UML § verwijderd uit 3.1.2

0.209


GvK

Kleine aanpassingen aan H2 (m.u.v. §2.4) vóór inhoudelijke herziening door AS.

0.210


ES / GvK

Inhoudelijke aanpassing in H3 ingevoegd; H3

0.211


JoVi / GvK

H5 “Aanbevelingen” herzien; H5 conceptstatus

0.212


GvK

§ 2.4 conceptstatus

0.213


HvK / GvK

H6 (bijlage) inhoudelijk en redactioneel herzien;

0.214


GvK

H1 aangevuld en herzien; conceptstatus

0.215


RvdH / ES / GvK

Aangepast H4 ingevoegd

0.216


GvK

Ruzie met opmaakprofielen…

0.217


GvK

Redactionele & inhoudelijk aanpassingen aan H4

0.218


AS / GvK

Inhoudelijke aanpassingen aan H2; H2 conceptstatus

0.219


GvK

Stukje over SIMONA toegevoegd aan paragraaf 4.2.1;

0.220


JW

Aanpassing samenvatting

0.221


AS

Tekstuele aanpassingen; auteurs vermelden

AS

1e versie ter oplevering aan KC-leden, HAH e.a.

conceptstatus

conceptstatus

H4 conceptstatus

1.0

e

1 versie definitief

2003 0731

geïnteresseerden

Inhoudsopgave

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

State of the Art rapport KC KwaZo versie 1.0 – 31 juli 2003

1 1.1 1.2 1.3 1.4 1.5

Inleiding Doel rapport Doelgroep Definitie onderwerp Afbakening Leeswijzer

7 7 7 7 7 8

2 2.1 2.1.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5

Inleiding in kwaliteitszorg Kwaliteit Kwaliteit binnen de informatievoorziening Kwaliteitszorg Kwaliteitszorg algemeen Continue verbetering Geschiedenis Statistiek in de kwaliteitszorg Statistische Procesbeheersing Kwaliteitssystemen Kwaliteitskosten Algemeen. Software Quality Assurance. Achtergronden bij kwaliteitskosten Bronvermelding :

9 9 11 11 11 12 13 14 15 16 19 19 21 22 23

3 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.2.1 3.2.2

De markt van ‘Kwaliteitszorg Methoden’ voor Systeemontwikkeling Kwaliteitszorgmethoden Proces Product People Performance Leveranciers Internationaal Nationaal

25 25 25 30 31 32 32 33 33

4 4.1 4.1.1 4.1.2 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2

Stand van zaken binnen Rijkswaterstaat Context Systeemontwikkeling binnen V&W toegespitst op RWS Pilots Inventarisatie Methoden van kwaliteitszorg bij systeemontwikkeling binnen AVV Methoden van kwaliteitszorg bij systeemontwikkeling binnen MD Toekomstverwachtingen Met betrekking tot het vakgebied Met betrekking tot V&W en RWS

35 35 35 36 37 37 39 40 40 40

5 5.1 5.2 5.3

Aanbevelingen m.b.t. kwaliteitszorg systeemontwikkeling Aanbevelingen m.b.t. implementatie van kwaliteitszorg Aanbevelingen m.b.t. kennisverwerving over kwaliteitszorg Voortzetting Kenniscentrumactiviteiten

42 42 43 43

4

6 6.1 6.1.1 6.1.2 6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.3 6.4

Bijlage: System life cycle: ontwikkeling en beheer Inleiding Systeemontwikkeling in de praktijk Relatie systeemontwikkeling en beheer bij greenfield projecten System life cycle Definitie system life cycle Wanneer wordt er getoetst Wie toetsen er Waarop wordt er getoetst Ontwikkeling helpt beheer en andersom Gebruikte documentatie

44 44 44 45 46 46 46 48 49 50 50

Lijst van figuren Figuur 2.1 Kwaliteit is zorgen voor tevreden klanten Figuur 2.2 Kwaliteit is zoeken naar evenwicht Figuur 2.3 Kwaliteitsbeleving Figuur 2.4 Kwaliteit is : “precies goed” Figuur 2.5 Dimensies van kwaliteit Figuur 2.6 Kwaliteitszorg als discipline Figuur 2.7 De drie elementen van kwaliteitszorg Figuur 2.8 Borging van kwaliteitszorg Figuur 2.9 Dr. W. Edwards Deming (1900-1993) Figuur 2.10 Mr. Philip B. Crosby (1926-2001) Figuur 2.11 Devies van een kwaliteitssysteem Figuur 2.12 Kwaliteitssysteem in drie blokken Figuur 2.13 Opbouw van een kwaliteitssysteem Figuur 2.14 Hiërarchie van kwaliteitsdocumenten Figuur 2.15 Projectspecifiek kwaliteitssysteem Figuur 2.16 Auditplan opstellen Figuur 2.17 Opbouw totale kwaliteitskosten Figuur 2.18 Optimale verhouding van kwaliteitskosten Figuur 2.19 Ontwikkelstadia van kwaliteitskosten Figuur 3.1 INK Managementmodel Figuur 3.2 De 5 niveaus van CMM Figuur 3.3 De 9 documenten van ISO 15504 Figuur 3.4 Procesarchitectuur PRINCE2 Figuur 3.5 Kwaliteitseigenschappen van ISO 9126 Figuur 6.1 Beheren kleine b + pijplijnmodel + AVB


5

9 9 10 10 11 11 12 13 13 13 16 17 17 18 18 19 22 22 23 26 26 28 29 31 47

SAMENVATTING Dit State of the Art rapport is samengesteld door het Kenniscentrum Kwaliteitszorg voor Systeemontwikkeling (KC KwaZo SO). In dit rapport wordt een overzicht gegeven van methoden en technieken die betrekking hebben op de systeemontwikkeling zoals die plaatsvindt binnen V&W en RWS in het algemeen en binnen de AVV en de MD in het bijzonder. Het rapport dient als vademecum, als “richtingwijzer” voor toekomstig werk, als “aanwijzer” van mogelijke kennishiaten en als “wegwijzer” voor nieuwe medewerkers. Omdat ‘kwaliteit’ zo’n breed begrip is, begint het rapport met een algemene beschouwende inleiding wat kwaliteit precies is en de weg die naar de huidige inzichten over kwaliteit heeft geleid. Ook wordt ingegaan op de zogenaamde ‘kwaliteitskosten’, zoals preventiekosten (bijv. het opleiden van personeel), controlekosten (bijvoorbeeld reviews, testen), en foutenkosten (bijv. het documenteren van wijzigingen). Daarna wordt een overzicht gegeven van de nationaal en internationaal beschikbare methoden voor kwaliteitszorg voor systeemontwikkeling. Deze methoden kunnen worden onderverdeeld naar vier verschillende aandachtsvelden: (1) proces, (2) product, (3) people en (4) performance. • Onder 1 (proces) vallen modellen om het kwaliteitsniveau van een organisatie te bepalen. Voorbeelden van dit soort modellen zijn het Capability Maturity Model (CMM) en het INK Management Model. Deze modellen kunnen enerzijds door organisaties worden gebruikt voor zelfanalyse als hulpmiddel in een verbeteringsproces. Anderzijds kunnen ze worden gebruikt om het kwaliteitsniveau van opdrachtnemers te bepalen. Specifiek voor systeemontwikkeling is er life cycle management. • Bij 2 (product) horen methodieken die de kwaliteit van het eindproduct moeten borgen, niet alleen in termen van de geboden functionaliteit, maar vooral ook m.b.t. de overige eigenschappen, zoals documentatie of beheerbaarheid. Voorbeelden van dit soort methodieken zijn de ISO-9126 standaard, de J-STD-016 documentatiestandaard en ook ITIL. • Methodieken bij 3 (people) betreffen met name een goed human resource management, specifiek gericht op systeemontwikkeling. • Bij 4 (performance) gaat het om methodieken om de productiviteit / effectiviteit te verbeteren van de organisatie die systeemontwikkeling doet. Een voorbeeld hiervan is projectbeheersing met behulp van PRINCE2. Vervolgens is een overzicht gemaakt van de methodieken, standaarden en hulpmiddelen die worden gebruikt in de diverse afdelingen van AVV (IB, BI, VM) en de MD voor diverse soorten van toepassingen. Veelgebruikt zijn onder andere de J-STD-016 documentatie standaard, ITIL, de Custom Development Method van Oracle en PRINCE2 voor projectmanagement. Prototypes / pilots vormen een apart aandachtspunt: het spanningsveld tussen enerzijds de noodzaak tot snelle realisatie en anderzijds de kwaliteitszorg die initieel vertragend lijkt te werken, maar zich naderhand in beheersbaarheid terugbetaalt. De verwachting is dat binnen RWS met name INK en CMM dominant gebruikt zullen worden en dat verder de life cycle visie een belangrijke rol gaat spelen. Tot slot worden een aantal aanbevelingen gedaan. In de eerste plaats wordt geadviseerd om life cycle management voor beheer vorm te geven, kosten van beheer zichtbaar te maken en om de werkwijze van systeemontwikkeling verder te standaardiseren binnen het DVM-domein. Een tweede set aanbevelingen betreft kennisverwerving op het gebied van metrieken, CMM in relatie met INK en het uitwerken van een oplossing voor het spanningsveld tussen prototypes en kwaliteitszorg.


6

1 Inleiding 1.1 Doel rapport

Het doel van het rapport is het beschrijven en vastleggen van de “State of the Art” van het Kenniscentrum Kwaliteitszorg voor systeemontwikkeling. Ofwel het geven van inzicht in welke mate en op welke wijze zorg aan kwaliteit wordt besteed bij de ontwikkeling van systemen binnen de ICTontwikkelingsafdelingen van AVV en MD. Welke processen bij systeemontwikkeling nodig zijn, en welke methoden en technieken daarbij gebruikt kunnen worden, met daarbij een accent op de aspecten die door de leden van het kenniscentrum Kwaliteitszorg voor systeemontwikkeling als belangrijk worden gezien bij de uitvoering van hun werk. Het is de bedoeling dat het rapport kan dienen als vademecum, als “richtingwijzer” voor toekomstig werk, als “aanwijzer” van mogelijke kennishiaten en als “wegwijzer” voor nieuwe medewerkers. Merk op dat de voorliggende versie een eerste versie is, waarin ongetwijfeld onderwerpen niet belicht of onderbelicht gebleven zijn. Bij voldoende belangstelling zal dat in de toekomst opgepakt worden. 1.2 Doelgroep

De doelgroep van het rapport bestaat uit : • het management, IB-staf • het KC zelf • de medewerkers van AVV en MD die met systeemontwikkeling te maken hebben. Het rapport wordt dan ook beschikbaar gesteld aan andere afdelingen binnen AVV en MD en diensten binnen RWS die zich bezighouden met systeemontwikkeling. 1.3 Definitie onderwerp

“Systeemontwikkeling” is een breed onderwerp. Een systeem omvat in het algemeen software én hardware. Voor dit rapport gaan wij uit van de ontwikkeling van software, de ontwikkeling van hardware laten we buiten beschouwing. Maar : de gekochte hardware waarop de ontwikkelde software draait behoort ook tot het systeem. En daarmee behoort het verwervingsproces (o.a. opstellen van eisen, selectie van leveranciers) van die hardware ook tot de “systeemontwikkeling”. Kwaliteitszorg in systeemontwikkeling staat voor het verbeteren van de kwaliteit van systemen door de kwaliteit van het (systeemontwikkeling)proces te verbeteren. 1.4 Afbakening

In dit rapport wordt een overzicht gegeven van methoden en technieken die betrekking hebben op de systeemontwikkeling zoals die binnen AVV/IB en de MD plaatsvindt. Er wordt geen beperking opgesteld t.a.v. het soort systeem dat ontwikkeld wordt, anders dan dat er geen aandacht wordt besteed aan hardwareontwikkeling. Dit rapport handelt over het systeemontwikkelingsproces. Aan de AO gerelateerde kwaliteitsaspecten behoren onderdeel te zijn van de projectplannen.


7

1.5 Leeswijzer

Het rapport is na deze inleiding als volgt opgebouwd : Hoofdstuk 2 geeft een algemene inleiding op het onderwerp kwaliteitszorg. Belicht worden o.a. verbeterprocessen, de geschiedenis van kwaliteitszorg en kwaliteitskosten. Hoofdstuk 3 geeft een inventarisatie van kwaliteitszorgmethoden, gerangschikt naar de aspecten proces, product, people en performance. Daarnaast worden verschillende leveranciers van kwaliteitszorgmethoden belicht. Hoofdstuk 4 belicht de stand van zaken zowel globaal binnen Rijkswaterstaat als meer gedetailleerd binnen AVV en MD. Hoofdstuk 5 bevat aanbevelingen van het Kenniscentrum met betrekking tot de kwaliteitszorg voor systeemontwikkeling Bijlage hoofdstuk 6 is geheel gewijd aan het begrip “System life cycle”


8

2 Inleiding in kwaliteitszorg Kwaliteit is het steeds beter kunnen voldoen aan de verwachtingen van de klant. Leidinggevenden en medewerkers geven samen vorm en inhoud aan kwaliteitszorg en daarmee aan het proces van dienstverlening. Kwaliteitszorg is het op gang brengen van een proces binnen de organisatie, waardoor men in staat is de klant de beloofde dienstverlening te leveren. Centraal daarin staat de uitdaging te werken aan concrete verbeteracties waarbij voortdurend de creativiteit van zoveel mogelijk medewerkers wordt benut. Op die manier wordt getracht de dienstverlening te optimaliseren en de organisatie in al haar facetten te verbeteren. Overheidsorganisaties zullen in de komende jaren onder voortdurende budgetdruk aan de toenemende kwaliteitseisen van burgers en bedrijven moeten voldoen. Het functioneren van deze organisaties moet worden verbeterd en de dienstverlening beter op de wensen van burgers en bedrijven afgestemd. Deze doelstellingen kunnen worden gerealiseerd door de invoering van kwaliteitszorg. Kwaliteitszorg bij overheidsinstellingen staat in Nederland echter nog in de kinderschoenen. 2.1 Kwaliteit

Kwaliteit is een veel gebruikt begrip. Maar wat bedoelen we nu eigenlijk met kwaliteit? In de praktijk blijkt dat ieder individu met kwaliteit iets anders bedoelt. Het blijkt dat het begrip “kwaliteit” een abstract begrip is. Het kan pas concreet worden als het ergens op wordt toegepast: kwaliteit van de koffie, kwaliteit van MS Word, kwaliteit van een project waarbij een systeem wordt gerealiseerd. Onderstaande figuren geven een tweetal beelden weer zoals kwaliteit vaak wordt opgevat.

Figuur 2.1 Kwaliteit is zorgen voor tevreden klanten Kwaliteit is: zoeken naar evenwicht.

Figuur 2.2 Kwaliteit is zoeken naar evenwicht


9

Ieder individu beleeft kwaliteit op een andere manier. In onderstaande figuur proberen wij u duidelijk te maken hoe dat komt. Stel u wilt een huis laten bouwen door een architect. U heeft dan een bepaald beeld voor ogen hoe u dat huis ziet. Dit noemen we ook wel uw referentiekader . Tijdens een onbewust proces creëert u bepaalde verwachtingen die u later in uw gedachten omzet in eisen. Met uw eisen op zak begint de architect aan de bouw van uw huis. En nu komt het begrip kwaliteitsbeleving om de hoek kijken. Vanaf het moment dat u uw huis te zien krijgt, bent u al of niet tevreden over de kwaliteit afhankelijk van het feit of het al dan niet aan uw verwachtingen voldoet.

Figuur 2.3 Kwaliteitsbeleving Zoals ook uit onderstaande figuur blijkt, is het de kunst om niet te weinig maar ook beslist niet te veel kwaliteit te leveren. Beter dan goed bestaat eigenlijk niet!

Figuur 2.4 Kwaliteit is : “precies goed” Ook al is kwaliteit een abstract begrip dat door ieder individu anders wordt uitgelegd, toch willen we u de volgende officiële definitie niet onthouden. Volgens [ISO 8402] is kwaliteit: Het geheel van eigenschappen en kenmerken van een product of dienst dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende behoeften.


10

Men begrijpt dat vooral die laatste toevoeging, “vanzelfsprekende behoeften”, voer voor juristen is.

2.1.1

Kwaliteit binnen de informatievoorziening

Om een nogal persoonlijk, abstract begrip als kwaliteit handen en voeten te geven is opsplitsing van dat begrip kwaliteit wenselijk. Zo’n opsplitsing kan plaatsvinden op basis van de verschillende invalshoeken van waaruit informatievoorziening kan worden beschouwd. Wij onderscheiden drie dimensies: • Procesdimensie: de ontwikkeling van het informatiesysteem door deskundigen samen met de gebruiker (opdrachtgever en opdrachtnemer). • Twee aspecten van de productdimensie: o Statische dimensie: de intrinsieke eigenschappen van het informatiesysteem en de documentatie, gezien vanuit het standpunt van de ontwikkelaar en van de toekomstige beheerder. o Dynamische dimensie: het functioneren van het systeem, gezien vanuit het standpunt van de gebruiker. • Informatiedimensie: de informatie die door het systeem als uitvoer wordt geproduceerd.

Figuur 2.5 Dimensies van kwaliteit

2.2 Kwaliteitszorg 2.2.1

Kwaliteitszorg algemeen

Het managen van kwaliteit kan samengevat worden in het begrip kwaliteitszorg. Onderstaande figuur laat zien wat onder kwaliteitszorg wordt verstaan:

Figuur 2.6 Kwaliteitszorg als discipline


11

Kwaliteitszorg heeft drie kenmerken: • Klantgerichte kwaliteit: een belangrijk doel van kwaliteitszorg in commerciële dienstverlening is het vergroten van de klanttevredenheid. • Kwaliteit wordt bepaald door mensen: de totale kwaliteit wordt in hoge mate bepaald door de kwaliteit van de samenwerking tussen mensen in de organisatie. • Kwaliteitszorg is een continu proces: kwaliteitszorg is een proces gericht op voortdurende verbetering van de concurrentiepositie van de eigen organisatie. Samengevat onderkennen we dus de volgende drie elementen van kwaliteitszorg:

Gericht op klanttevredenheid

Samenwerking tussen mensen

Continu proces

Figuur 2.7 De drie elementen van kwaliteitszorg Kwaliteit is een relatief begrip. De gewenste kwaliteit is (per project en) per product verschillend. De definitie van kwaliteitszorg kan dus ook niet absoluut zijn. De essentie van kwaliteitszorg wordt weergegeven in de uitdrukking: “kwaliteit is zeggen wat je doet en doen wat je zegt!”. Om kwaliteit in een organisatie te waarborgen is een systematische aanpak nodig, ondersteund door een kwaliteitssysteem. Zo’n kwaliteitssysteem omvat een aantal aspecten die in beginsel alle belangrijk zijn en die alle aan de orde moeten komen bij de inrichting van het systeem. Er is ook een serie internationaal aanvaarde normen waarin de essentiële eisen voor een compleet kwaliteitssysteem zijn vastgelegd, de ISO 9000 normen. 2.2.2

Continue verbetering

Het proces van continue verbetering gaat uit van de simpele gedachte dat een gestructureerd probleemoplossend proces betere resultaten geeft dan een ongestructureerd. In plaats van te proberen om dingen beter te doen (iets wat elke organisatie wil) op een ongedefinieerde en intuïtieve wijze kan dat beter via een proces van continue verbetering gebeuren. Door toepassing van kwaliteitstechnieken is een inventarisatie te maken van de kwaliteitsproblemen, die aandacht vragen om opgelost te worden. Een systematische methode hiervoor is het Deming-wiel. Ook wel Deming-cirkel, of Plan-Do-Check-Act methode (PDCA-approach) genoemd.


12

Figuur 2.8 Borging van kwaliteitszorg

2.2.3

Geschiedenis

Wie kwaliteitszorg en -management in een historisch verband plaatst, zal tot de conclusie komen dat er al bijna honderd jaar sprake is van systematische zorg om kwaliteit van producten en van processen, van organisatie en arbeid. De praktijk van de bedrijfsvoering in organisaties — ondernemingen, non-profiten overheidsorganisaties — laat ten aanzien van kwaliteit en productiviteit zien dat er nog veel verbeterd en vernieuwd kan worden. Vele ondernemingen zijn — ondanks de sterk gestegen belangstelling voor ISO-certificering en voor zelfevaluaties van de bedrijfsvoering — nog ver verwijderd van het prestatieniveau waaraan het predikaat ‘Integrale Kwaliteit’ kan worden gehangen. Een korte opsomming van de geschiedenis van de kwaliteitszorg. Beginnende bij Shewhart, dan de voortzetting vanuit Japan onder leiding van generaal McArthur, die achtereenvolgens Deming, Juran en Crosby haalde om de kwaliteitszorg te promoten.

Figuur 2.10 Mr. Philip B. Crosby (1926-2001) Figuur 2.9 Dr. W. Edwards Deming (1900-1993)


13

2.2.4

Statistiek in de kwaliteitszorg

De toepassing van statistiek in de kwaliteitszorg heeft een lange geschiedenis. Het merendeel van de pioniers op het gebied, zoals Walter A. Shewhart and W. Edwards Deming, noemen zichzelf statistici. Statistisch denken in het bedrijfsleven betekent dat alle inspanningen gezien worden als een serie verbonden processen, dat al deze processen aan variatie onderhevig zijn, en dat het beperken van deze variatie de sleutel is voor continue verbeteringen. Kwaliteit wordt vanuit twee oogpunten bekeken. Het traditionele, Westerse perspectief gaat uit van vaststaande specificaties waaraan een product moet voldoen (denk aan de ISO 9000 normenserie). Integrale Kwaliteitszorg (Total Quality Management) gaat daarentegen uit van continue verbetering van producten en diensten. De opkomst van Integrale Kwaliteitszorg als managementfilosofie heeft geleid tot wat wel de derde industriële revolutie genoemd wordt. Volgens Deming, de grondlegger van de Integrale Kwaliteitszorg, geeft kwaliteitsverbetering de aanzet tot een kettingreactie. Door kwaliteitsverbetering stijgt de productiviteit hetgeen lagere kosten met zich meebrengt, waardoor de prijzen concurrend kunnen worden, zodat het marktaandeel vergroot en het bedrijf sterker wordt. Tegenwoordig moeten bedrijven continu aan verbeteringen blijven werken om te kunnen overleven. Zelfs sterk traditionele bedrijven, zoals Hoogovens, hebben Integrale Kwaliteitszorg noodgedwongen moeten omarmen. Integrale Kwaliteitszorg heeft een sterk statistische achtergrond. Deming baseerde zich op de ideeën van zijn leermeester Shewhart, die als eerste het stochastisch karakter van een productieproces onderkende. Shewart begreep dat de variatie van een beheerst proces, een proces dat stabiel gedrag vertoont, alleen teruggebracht kan worden aan de hand van inzicht in de structuur van de variatie. Later zijn andere concepten aan Integrale Kwaliteitszorg toegevoegd, bijvoorbeeld just-in-time. De concepten vormen één geheel, en mogen dus niet los van elkaar worden gezien. Voor just-in-time is bijvoorbeeld een kwalitatief hoogwaardig productieproces nodig. Door Shewhart en Deming werd kwaliteitsverbetering van de fabriekspoort (massa-inspectie) verlegd naar de fabrieksvloer. De laatste ontwikkeling is het inbouwen van kwaliteit tijdens de ontwikkelingsfase van het productieproces, waardoor kwaliteitsverbetering nog eerder plaatsvindt. De belangrijkste man achter deze ontwikkeling is de Japanner Taguchi. Zijn methoden voor het robuust ontwerpen van een productieproces grijpen terug op de statistische theorie van proefopzetten. Kwaliteitszorg impliceert dus het omgaan met, het beheersen van en waar mogelijk het reduceren van variatie. De taal van variatie wordt het beste verstaan door gebruik te maken van statistiek en verklaart ook het ruime gebruik dat altijd is gemaakt van statistische methoden en technieken binnen de kwaliteitszorg. Maar het omgaan met variatie betekent meer dan alleen de toepassing van statistische methoden en technieken. Het vraagt vooral om inzicht in de denkwijze die aan die methoden en technieken ten grondslag ligt. Het vraagt om wat de laatste tijd weer vaker wordt aangeduid als het statistische denken in het bedrijf. Statistisch denken gaat ervan uit dat: • al het werk wordt gerealiseerd in een systeem van onderling verbonden processen, elk met een klant – leverancier verhouding; • alle processen variatie vertonen; • bronnen van variatie globaal kunnen worden onderscheiden in variatie veroorzaakt door gewone oorzaken en variatie veroorzaakt door speciale oorzaken; • het begrijpen van de herkomst van beide bronnen van variatie de sleutel is voor het reduceren van variatie; en • het reduceren van variatie op zijn beurt weer de sleutel is tot kwaliteitsverbetering, productiviteit en winstgevendheid.


14

2.2.5

Statistische Procesbeheersing

Een van de belangrijkste toepassingen van het statistisch denken in het bedrijfsleven is bekend geworden onder de naam Statistische Procesbeheersing – in vakkringen bekend geworden onder de afkorting SPC (Statistical Process Control). De fundamenten van SPC werden reeds in de jaren twintig gelegd. Men realiseerde zich in die tijd dat niet naar de producten zelf, maar naar de onderliggende processen moest worden gekeken om echt tot vermindering van het aantal fouten te komen. De hoge kosten die gepaard gaan met uitval en reparatie van eindproducten, die niet aan de specificaties voldoen, is een belangrijke katalysator geweest om over te gaan naar een meer preventieve aanpak. Daarmee verschoof de aandacht van het product (en later ook de dienst) naar het voortbrengende proces. Het pionierswerk hiervoor is verricht door Dr. Walter A. Shewhart. Alhoewel het gebruik van statistische methoden zijn nut tijdens de Tweede Wereldoorlog in de wapenindustrie had bewezen, maakten deze methoden geen opgang in de consumentenindustrie vlak daarna. Kwaliteit was toen ondergeschikt aan kwantiteit. Heel anders ging het toen in Japan. Daar werden, met name onder invloed van de Amerikaan Dr. W. Edwards Deming, de ideeën van Shewhart in de volle breedte toegepast. Dus niet alleen bij productieprocessen, maar ook bij de processen van inkoop, verkoop, administratie, planning et cetera. Immers, volgens Deming geldt dat kwaliteitsbeheersing een zaak is van iedereen. Hij formuleerde veertien punten die erop gericht waren een betere omgeving voor het proces van voortdurende verbetering te creëren. Pas in het begin van de jaren tachtig van de twintigste eeuw nam in de westerse wereld de belangstelling voor kwaliteit sterk toe. Veel sterker dan eerder werd nu ook aandacht besteed aan de context en werden de consequenties voor de bedrijfsvoering herkend. De ontwikkelingen in Nederland op dit terrein lopen min of meer parallel aan die in de overige westerse landen. Eind tachtiger jaren en begin negentiger jaren van de twintigste eeuw zijn veel bedrijven overgegaan op een aanpak gebaseerd op SPC. In het boek getiteld “Statistische Procesbeheersing in Bedrijf” wordt een handleiding gegeven voor het implementeren en verankeren van SPC. Zes Sigma is een kwaliteitsmanagement programma, dat oorspronkelijk is ontwikkeld bij Motorola. Het is een klantgedreven benadering voor kwaliteitsmanagement en biedt een alomvattend plan voor procesverbetering. In 1987 lanceerde de hoogste baas van Motorola, Bob Galvin, het 6σ (spreek uit: Zes Sigma of Six Sigma) programma in zijn bedrijf. Dit kwaliteitsprogramma behelst een uniforme aanpak zodanig dat in alle processen van het bedrijf een hoger kwaliteitsniveau bereikt wordt. Dit niveau wordt geassocieerd met 6σ en heeft daarom iets mysterieus over zich. Het 6σ-kwaliteitsniveau is equivalent met een niveau van 3,4 fouten per miljoen. Motorola stelde zichzelf als doel om in 1989 het kwaliteitsniveau met een factor 10 te verbeteren in het gehele bedrijf, vervolgens in 1991 met een factor 100 en uiteindelijk in 1992 wilde men de status van 6σ bereiken. Deze doelstellingen golden voor alle processen in het bedrijf, van productie tot marketing, van human resources tot ontwikkeling. Het programma was zo succesvol dat Motorola reeds in 1988, als een van de eerste bedrijven, de Malcolm Baldrige National Quality Award ontving van de Amerikaanse President. In 1997 waren bij Motorola ongeveer 65.000 van de in totaal 142.000 medewerkers verdeeld over 5000 teams betrokken in het programma. In 1997 werd circa 5 miljard gulden bespaard met behulp van dit programma. De 6σ aanpak overtreft de meer traditionele aanpakken van TQM, ISO en SPC vooral vanwege de enorme financiële successen. Het initiatief ligt heel duidelijk bij de allerhoogste baas. De projecten worden door het kader uitgevoerd en beperken zich niet tot productie alleen. Het motto dat veelal gebezigd wordt is: “Show me the data and show me the money” Joseph Juran’s belangrijkste bijdrage aan het denken over kwaliteitsmanagement is “zijn methode voor het bepalen van de vermijdbare en onvermijdbare kosten van kwaliteit”, schrijft Carol Kennedy in haar boek


15

Guide to the Management Gurus. Joseph Juran veranderde het vage begrip kwaliteit in een methode om kosten te besparen en deze methode werd een uiterst effectief wapen in de strijd tegen de concurrentie. Joseph Juran (inmiddels ruim negentig jaar) wordt vaak in één adem genoemd met zijn tijdgenoot W. Edwards Deming. Beide interesseerden zich voor kwaliteitsbeheersing en beide boekten hun eerste successen in Japan. De Japanners hadden al kennis gemaakt met de statistische methode van W. Edwards Deming, toen Juran’s boek Quality Control Handbook in 1951 uitkwam. Het boek wordt ook wel ‘de bijbel voor kwaliteitscontroleurs genoemd’. Op uitnodiging van de Japanners hield Juran in 1953 enkele lezingen voor topmanagers en hielp ze verder in hun denken over en streven naar kwaliteitscontrole. In 1966 voorspelde Juran dat de Japanners vanwege hun inspanningen binnen twintig jaar superieur zouden zijn op het gebied van kwaliteit - en hij kreeg gelijk. Dankzij dit succes verwierf hij in de Verenigde Staten de waardering die hij verdiende. Juran ontwikkelde net als goeroes als Charles Handy, Peter Drucker en Rosabeth Moss Kanter een visie voor de toekomst. Net als Moss Kanter is zijn belangrijkste insteek het menselijk kapitaal. Voor Juran is kwaliteit altijd verbonden geweest met menselijke verhoudingen en teamgeest. Juran in het kort: Hij kreeg zijn liefde voor kwaliteit in de jaren twintig bij Western Electric, een bedrijf waar de kwaliteitseisen hoog waren. Juran was een van de vijfduizend inspecteurs die de onderdelen controleerde. In de jaren veertig besloot hij voor zichzelf te beginnen als consultant. In 1980 ontving hij een speciale onderscheiding in Japan vanwege zijn verdiensten op het gebied van kwaliteitszorg.

2.3 Kwaliteitssystemen

De internationaal geaccepteerde definitie van een kwaliteitssysteem is, volgens ISO 8402: Een kwaliteitssysteem bestaat uit de organisatorische structuur, verantwoordelijkheden, procedures, processen en voorzieningen die nodig zijn voor het ten uitvoer brengen van kwaliteitszorg. Een kwaliteitssysteem beschrijft dus in feite wie waar op welk moment voor verantwoordelijk is en hoe alle taken uitgevoerd dienen te worden, opdat er een vooraf bepaalde kwaliteit bereikt kan worden. Het devies van een kwaliteitssysteem is dan ook:

Figuur 2.11 Devies van een kwaliteitssysteem


16

Een kwaliteitssysteem kan gevisualiseerd worden als een systeem bestaande uit een drietal blokken, zie onderstaande figuur.

Figuur 2.12 Kwaliteitssysteem in drie blokken Het blok getiteld kwaliteitsvoorwaarden duidt die zaken aan die onontbeerlijk zijn voor het leveren van kwaliteit. Dat zijn regels, voorschriften, methoden, technieken, hulpmiddelen, organisatiestructuur, taakbeschrijvingen enzovoorts. Om kwaliteit te kunnen uitdrukken is een kwaliteitsmetriek nodig. De vakbekwaamheid (persoonlijke kwaliteit) van de uitvoerders vormt de meest cruciale schakel in het gehele kwaliteitsgebeuren. Het blok getiteld onafhankelijke controle bevat audit-instrumenten om te kunnen controleren of datgene wat op kwaliteitsgebied wordt afgesproken, ook werkelijk zal worden gerealiseerd. Het projectspecifieke kwaliteitssysteem tenslotte is het kwaliteitssysteem dat is toegesneden naar een specifieke opdracht.

Figuur 2.13 Opbouw van een kwaliteitssysteem De opbouw van een kwaliteitssysteem, zoals in Figuur 2.13 te zien, bestaat uit


17

vijf lagen, namelijk: • Het kwaliteitsbeleid: wat is de doelstelling van kwaliteitszorg binnen uw organisatie? • De kwaliteitsorganisatie: hoe wordt kwaliteit ingebed in de organisatie? (welke medewerkers krijgen welke taken, welke overlegstructuren zijn er, enzovoorts) • De algemene procedures: kwaliteitsprocedures die algemeen toepasbaar zijn. • De specifieke procedures: kwaliteitsprocedures die meer specifiek toepasbaar zijn (bijvoorbeeld bij een bepaald soort opdrachten). • De werkinstructies, checklists, richtlijnen, voorbeelden enzovoort: de procedures opgedeeld in activiteiten (hoe bereiken we kwaliteit in onze dagelijkse werkzaamheden?). De hiërarchie van kwaliteitsdocumenten heeft een nauwe relatie met de opbouw van een kwaliteitssysteem, zoals blijkt uit onderstaande figuur. Het kwaliteitsbeleid en de kwaliteitsorganisatie worden beide vastgelegd in een kwaliteitshandboek. De algemene en specifieke procedures van een kwaliteitssysteem worden vastgelegd in kwaliteitssysteemprocedures en de werkinstructies, voorbeelden, checklists enzovoort worden vastgelegd in overige dagelijks te gebruiken kwaliteitsdocumenten.

Figuur 2.14 Hiërarchie van kwaliteitsdocumenten Bij de start van een project in een opdrachtgever-opdrachtnemer verhouding zijn vaak minimaal twee kwaliteitssystemen aanwezig: het kwaliteitssysteem van de klant en het kwaliteitssysteem van de leverancier.

Figuur 2.15 Projectspecifiek kwaliteitssysteem


18

In het ideale geval voldoen beide kwaliteitssystemen tenminste aan ISO 9001 en zijn ze wellicht gecertificeerd. Een projectspecifiek kwaliteitssysteem is een combinatie van deze twee kwaliteitssystemen dat de kwaliteitsspelregels beschrijft waaronder het project dient te verlopen. Dit is afgebeeld in Figuur 2.15. In Figuur 2.16 wordt getoond hoe de kwaliteit in een project wordt geregeld. Tijdens de opdrachtvoorbereiding wordt een risicobepaling gedaan om te kijken of het project uitvoerbaar is. Dit is een onderdeel van het opdrachtmanagement. Tijdens de projectvoorbereiding wordt een kwaliteitsplan gemaakt, waarin onder andere alle verificatie- en validatieactiviteiten worden beschreven die tijdens de projectuitvoering dienen te worden toegepast. Het opstellen van een kwaliteitsplan en de uitvoering daarvan zijn de verantwoordelijkheid van de projectmanager. De hoeveelheid en de zwaarte van kwaliteitsborgende acties is afhankelijk van het risico. Het kwaliteitsplan (de vertaling van de kwaliteitszorg naar het project) vormt een onderdeel van het projectplan.

Figuur 2.16 Auditplan opstellen Het is de verantwoordelijkheid van de projectleider te zorgen dat zijn project voldoet aan de overeengekomen kwaliteitsnormen. Vanuit de functie van het opdrachtmanagement wordt tenslotte een auditplan opgesteld, waarin wordt aangegeven welke audits op welk tijdstip als onderdeel van het opdrachtmanagement dienen te worden uitgevoerd.

2.4 Kwaliteitskosten

De volgende paragrafen geven een inzicht in de verschillende kostenposten die aan kwaliteit gerelateerd zijn. Paragraaf 2.4.1 schetst de kosten van kwaliteitszorg in ontwikkeling en ontwerp en is globaal toepasbaar. Paragraaf 2.4.2 geeft een invulling voor kwaliteitskosten bij softwareontwikkeling. Paragraaf 2.4.3 heeft overlap met 2.4.1, is ook globaal, maar maakt het geheel duidelijker door grafieken. 2.4.1

Algemeen.

Een kwaliteitskostenoverzicht legt een relatie tussen onderling beïnvloedbare activiteiten uitgedrukt in kosten. Via zo’n overzicht is het management in staat om mogelijkheden tot kwaliteitsverbetering en kostenverlaging te identificeren en eventuele gerichte actie op te starten. Bij periodiek opstellen van zo’n


19

overzicht wordt bovendien de mogelijkheid geschapen om de doeltreffendheid ten aanzien van kwaliteit en kosten van genomen maatregelen te beoordelen. Basis voor de kostenindeling is dat de ideale ontwerper zijn opdracht zodanig zal verwerken dat het ook te maken is en werkt volgens de wensen en eisen van de klant. Volgens deze definitie zou systeemtesten en modelbouw voor zo’n ideaal persoon niet nodig zijn. De eerste indruk die men heeft van een ontwerpafdeling is dat modelbouw en testen op betrouwbaarheid inherent zijn aan het ontwikkelen. Met voorgaande definitie kunnen we dit ook beschouwen als controles op hetgeen ontworpen is. In principe is het zo dat we bij een ideaal ontwerp geen modellen behoeven te bouwen en ook geen verzoeken tot wijziging na vrijgave ontvangen. Als eisen en wensen van de gebruiker tijdig bekend zijn, kan de ontwerper vanuit de opdracht die hij ontvangt deze vertalen in normen betreffende: • functie; • bedrijfszekerheid; • veiligheid; • kostprijs; • vormgeving; enz. Het checken van het ontwerp en de activiteiten tijdens het ontwerpproces tegen deze normen plus het corrigeren van eventuele afwijkingen benoemen we in dit licht als kwaliteitskosten. We houden hierbij de volgende indeling aan: • preventiekosten; • controlekosten; • foutenkosten: intern; • foutenkosten: extern. Deze kostensoorten beïnvloeden elkaar onderling. Met meer of minder preventie kan men zowel controle- als foutenkosten beïnvloeden en deze categorie omvat dus de hoofdelementen waarmee men het optimum van de kosten als functie van de kwaliteit bepaalt: Preventiekosten Preventiekosten zijn de kosten die we maken om de kans op kwaliteitsafwijkingen te verkleinen. Voorbeelden: • training van ontwerpers; • vroegtijdig inschakelen leveranciers; • process capability studies; • opzet van een beheersingssysteem. Controlekosten Controlekosten zijn de kosten die we maken om te voorkomen dat fouten in het ontwerp bij de klant terechtkomen. Voorbeelden: • bouwen van een model; • testen op bedrijfszekerheid; • testen van componenten en materialen; • formele ontwerpbeoordeling. Met controlekosten tracht men een optimum te bereiken tussen interne en externe foutenkosten. Interne foutenkosten Interne foutenkosten zijn die kosten die ontstaan tengevolge van ontwerpfouten en tekortkomingen vóór vrijgave van het ontwerp aan productie. Voorbeelden: • het documenteren van wijzigingen;


20

•

extra onderzoek om fouten tijdens test of modelbouw geconstateerd te elimineren.

Externe foutenkosten Externe foutenkosten zijn die kosten die ontstaan bij de verwerker van de ontwerpinformatie en de maker en de gebruiker van het product, tengevolge van ontwerpfouten en tekortkomingen aldaar geconstateerd na vrijgave van het ontwerp aan productie. Voorbeelden: • bijwerken van tekeningen wegens slechte leesbaarheid; • het documenteren van wijzigingen; • het bouwen van modellen en het uittesten hiervan tengevolge van wijzigingen; • extra gereedschapskosten tengevolge van wijzigingen; • extra voorraad en bewerkingskosten tengevolge van wijzigingen; • het verlenen van ondersteuning aan productie en service; • het bijwerken van servicedocumentatie. Onderzoek bij Rank Xerox en Ericsson heeft aangetoond dat het volgens deze indeling niet ongewoon is dat 60% van de totale projectontwikkelingskosten onder kwaliteitskosten valt. Siemens besteedt alleen aan design reviews reeds 10-15 % van zijn totale projectkosten. Evenals bij kwaliteitskosten in de productiefase is het grote nut van zo’n analyse het aantonen om welke bedragen het gaat. Ook om duidelijk te maken wat de onderlinge beïnvloedbaarheid is tussen preventie-, controle- en foutenkosten; en om aan te tonen waar de grote vissen zitten die moeten worden gevangen voor kostenverlaging en winstvergroting. Deze doelstellingen leren ook dat een globale schatting van de kosten reeds voldoende inzicht geeft om acties tot verbetering te rechtvaardigen en gericht op te starten. 2.4.2

Software Quality Assurance.

Het doel van Software Quality Assurance is producten proceskwaliteit constant te volgen en daar waar mogelijk snel te kunnen reageren op afwijkingen van de gestelde normen en/of standaards. Zodoende kan men een product verkrijgen dat tegen minimale kosten volledig voldoet aan de wensen en eisen van de klant. Binnen dit kader kan men aan Software Quality Assurance de volgende functies toekennen: • Nagaan of het product (programma incl. documentatie) voldoet aan de eisen van de klant. De effectiviteit. • Meten of het product systematisch tot stand gekomen is binnen het gehele ontwikkelingstraject. De efficiency. • Registratie en analyse van gemaakte fouten en/of afwijkingen van de specificaties. • Initiatie en controle op voortgang van preventieve en correctieve acties gebaseerd op functie 3. Dat een strikter kwaliteitsbeleid ook binnen softwareontwikkeling nodig is, moge blijken uit de volgende trends: • Software wordt telkens meeromvattend en duurder. De kosten stijgen steeds sterker ten opzichte van bijvoorbeeld hardware. • Computerhardware wordt betrouwbaarder, makkelijker verkrijgbaar en toepasbaar waardoor een enorme groei van software wordt gerealiseerd met een grote invloed op het menselijk welzijn. • In veel apparatuur, bijvoorbeeld huishoudelijke apparaten, wordt tegenwoordig gebruik gemaakt van computertoepassingen waardoor deze apparatuur gevoelig wordt voor storingen in de hardware en de software.


21

2.4.3

Achtergronden bij kwaliteitskosten

Hieronder is weergegeven hoe de verschillende soorten kwaliteitskosten zich verhouden. Het navolgende is een uittreksel uit een Engelstalig artikel. The graph below shows that there is a minimum Total Quality cost, which is a combination of prevention, appraisal and failure. Reducing any of these reduces the total. The key to minimum cost, is striking the correct balance between the three.

Figuur 2.17 Opbouw totale kwaliteitskosten Clearly prevention reduces both appraisal and failure costs, however eventually the cost of prevention itself starts to increase the total cost and so this must be controlled and set at an effective level. The minimum total cost, is shown below as being achieved at 98% perfection. This percentage is also known as best practice. That is, the cost of achieving an improvement outweighs the benefits of that improvement.

Figuur 2.18 Optimale verhouding van kwaliteitskosten


22

The graph below shows the four stages of Total Quality acceptance / implementation and what happens theoretically to the four segments of the

cost of quality:

Figuur 2.19 Ontwikkelstadia van kwaliteitskosten

2.5 Bronvermelding :

• •

• • •

• • •


Integrale kwaliteitszorg, Erik Demeulmeester, Dominiek Callewier – 1997 (http://www.managementboek.nl/promopaginas/boeken/902092978x.ht m) De excellente overheidsorganisatie Frans Bentlage, J.B. Boelens, J.A.M. Kip – 1998 (http://www.managementboek.nl/boekeninfo.asp?CODE=90262207725270 46&PHPSESSID=45318d901acab42522bdff4722a52bf3) Does & Van den Heuvel (1999), Zakelijk Verbeter Programma Herman Raadschelders, Mart den Rooijen Kwaliteitszorg en statistiek in het laboratorium Studiegids 96/97 Economische Wetenschappen Erasmus Universiteit Rotterdam http://www.intermediair.nl/archief/goeroes/juran.html Kwaliteitsmanagement en organisatieontwikkeling 2e druk prof. dr. T. Wentink Bruggen, R. van, Heijes, H.,Knol, H.J., Schoonhoven, B. (1991) Kwaliteitszorg in informatisering Academic Service

23

• • • • • •


Deming, W.E. (1994), De crisis overwonnen, Kluwer Bedrijfswetenschappen, Deventer. Does, R.J.M.M. en E.R. van den Heuvel (1998), Six Sigma levert Motorola jaarlijks vijf miljard gulden op, in: Kwaliteit in Bedrijf 14/3, blz. 14-17. Does, R.J.M.M., K.C.B. Roes en A.Trip (1996), Statistische Procesbeheersing in Bedrijf, Kluwer Bedrijfswetenschappen, Deventer. Oudshoorn, K., E.R. van den Heuvel en R.J.M.M. Does (1998), Het 6σ kwaliteitsprogramma, in: Kwantitatieve Methoden 58, blz. 103-120. “Kwaliteitszorg in de praktijk”, auteurs: ir. J.G. Maas en ir. J. Bollen. Website www.educesoft.com, artikel van D. Wilson, van de Open University.

24

3 De markt van ‘Kwaliteitszorg Methoden’ voor Systeemontwikkeling In dit hoofdstuk wordt een beperkt overzicht gegeven van een aantal kwaliteitsborgingmethoden zoals die door de markt geleverd kunnen worden. 3.1 Kwaliteitszorgmethoden

De markt is te groot om hier in zijn volle omvang te beschrijven. Er zal daarom niet de suggestie gegeven worden dat hier een uitputtende opsomming van kwaliteitszorg methoden wordt gegeven. Er wordt gefocusseerd op typen van methoden. Er zijn dus verschillende invalshoeken waarlangs kwaliteitszorg van softwareontwikkeling kan worden ingericht. Vanuit praktijk en onderzoek ligt veel nadruk op de verbetering van de kwaliteit van het ontwikkelproces (software process improvement SPI). Het uitgangspunt hierbij is het verkrijgen van een betere grip op het proces van software/systeemontwikkeling zodat wij in staat zijn om betere producten te leveren. Dit grijpt dus aan op het proces. Andere typen van methoden besteden meer aandacht aan product, people en/of performance. De methoden zijn middelen en vormen geen doel op zichzelf. De methode zal moeten worden aangepast aan de specifieke bedrijfsdoelstellingen en bedrijfscultuur van onze organisatie. 3.1.1

Proces

IEEE/EIA 12207 IEEE/EIA 12207 1996/1997 (delen 0, 1 en 2) is de industriële implementatie van ISO/IEC 12207 1995. Het is een algemeen raamwerk voor software life cycle (levenscyclus) processen. Het bevat processen, activiteiten en taken die kunnen worden toegepast op software producten als onderdeel van een systeem, als standalone software product en als software service bij inkoop, levering, ontwikkeling, operatie, beheer en onderhoud. Het raamwerk bestaat uit drie soorten processen, primaire life cycle processen (inkoop, levering, ontwikkeling, operatie, beheer en onderhoud), ondersteunende processen (documentatie, configuratie beheer, quality assurance, verificatie, validatie, joint review, audit, probleemafhandeling) en organisatorische life cycle processen (management, infrastructuur, verbetering, training). De standaard kan onafhankelijk van ontwikkeltechnieken en -methodieken worden toegepast en is bruikbaar voor elk life cycle model (b.v. waterval, incrementeel, spiraal). De standaard is geschikt voor gebruik in contractuele overeenkomsten tussen leverancier en klant. ISO-normen Een algemene en bekende standaard voor borging en certificatie van de kwaliteit van de processen in een organisatie zijn de ISO-9000 standaarden. Deze zijn algemeen toepasbaar en niet specifiek toegesneden voor de software/systeemontwikkelende bedrijven. Voorbeelden zijn ISO 9001 (‘model voor de kwaliteitsborging bij het ontwerpen, het ontwikkelen en vervaardigen, het installeren en de nazorg’) dan wel ISO 9002 (‘model voor de kwaliteitsborging bij het vervaardigen en het installeren’). Daar softwareontwikkeling ook altijd het ontwerp en de nazorg behelst, zal een softwareontwikkelende organisatie altijd volgens ISO 9001 moeten worden gecertificeerd.


25

INK Managementmodel Het INK Managementmodel is een nadere invulling van het model dat door de EFQM (European Foundation for Quality Management) is ontwikkeld voor de evaluatie van de totale kwaliteit van een organisatie. Het model is algemeen toepasbaar en niet specifiek toegesneden voor softwareontwikkelende organisaties. De primaire doelstelling van het model is de ondersteuning van organisaties bij het uitvoeren van een self-assessment. De negen verschillende aandachtsgebieden waarop het INK Managementmodel zich richt, zijn weergegeven in Figuur 3.1. Bij de hiervoor genoemde methodes ligt de nadruk op het management van processen, waarbij in een aantal gevallen ook een paar van de randgebieden (vooral middelenmanagement) worden meegenomen. De reikwijdte van dit model is duidelijk groter. Anderzijds is het een meer beschrijvend model dat houvast biedt voor assessment, maar minder invulling geeft aan het antwoord op de vraag hoe een (volgend) kwaliteitsniveau kan worden bereikt.

Figuur 3.1 INK Managementmodel

CMM Dit is de bekendste methode voor het in kaart brengen van de kwaliteit van het softwareontwikkelproces is de door het Software Engineering Institute (SEI) ontwikkelde methode CMM (capability maturity model).

Figuur 3.2 De 5 niveaus van CMM


26

CMM is primair bekend als methode voor proces-assessment. Een assessment heeft tot doel het softwareontwikkelproces van een organisatie door te lichten. Daarbij wordt bepaald in hoeverre de diverse delen van het proces adequaat zijn ten opzichte van de doelstellingen die de organisatie zich heeft gesteld ten aanzien van het softwareontwikkelproces. Aan de hand van een assessment wordt een plan opgesteld en wordt actie ondernomen om verbeteringen in het softwareontwikkelproces te realiseren. Bij elk niveau kent CMM een aantal aandachtsgebieden, de zogenaamde KPA’s (key process areas). Dit zijn de gebieden waarvan CMM adviseert dat een organisatie die moet aanpakken om te groeien naar een hoger niveau van volwassenheid in haar softwareontwikkeling. Verder zijn voor elk van deze aandachtsgebieden activiteiten beschreven die bijdragen aan de realisatie van de doelen, die voor dat aandachtsgebied worden gesteld. CMM bevat daarmee een praktisch raamwerk dat aangeeft hoe men verbeteringen in de organisatie van het softwareontwikkelproces kan doorvoeren. CMMI Een praktisch probleem bleek in de afgelopen jaren het gebruik van eerdere CMM’s. Grote organisaties gebruikten bijvoorbeeld een software-CMM en een productontwikkeling-CMM. Dat was onnodig complex. Het Amerikaanse ministerie van Defensie gaf daarom de aanzet tot het integreren van die afzonderlijke CMM’s. Het moest de beste elementen uit de software- en systeemontwikkeling en de productontwikkelingversies samenbrengen. Dat is inmiddels gedaan en het resultaat heet CMMI, ofwel CMM Integrated. Kenners herkennen in CMMI een compromis. Het kent zowel de ‘continuous approach’ uit EIA/IS 731 (Electronic Industries Association Interim Standard 73) en de ‘staged approach’ uit software-CMM. Maar toch is ook een mogelijkheid tot bedrijfsbrede procesverbetering aanwezig. CDM CDM, Custom Development Method, is een door Oracle ontwikkelde en beproefde methodiek om projecten voor het bouwen van maatwerk software inhoudelijk en organisatorisch vorm te geven. CDM beschrijft de fasen, de daarin uit te voeren taken en de resulterende producten (deliverables) tijdens de ontwikkeling van een informatiesysteem. CDM voorziet in de ondersteuning van allerlei soorten projecten, van hele kleine tot grote projecten met vele mensjaren werk en doorlooptijden van meer dan een jaar. Bootstrap Bootstrap is eveneens een methode voor assessment en verbetering van het softwareontwikkelproces. Dit Esprit project had tot doel om gebaseerd op CMM, ISO 9000-3 en ESA-standaards te komen tot een geschikte methode voor softwarekwaliteitsverbetering. Een van de verschillen tussen CMM en Bootstrap is dat Bootstrap meer nadruk legt op een sterkte/ zwakte-profiel van de organisatie dan de niveau-indeling die CMM kenmerkt. Een softwareontwikkelende organisatie hoeft niet een aantal processen volledig onder controle te hebben alvorens men naar een hoger niveau kan, maar er wordt voor een groot aantal processen geanalyseerd in hoeverre de organisatie als geheel ze heeft ingericht. Door Bootstrap worden naast primaire ontwikkelprocessen als specificatie, ontwerp, programmering en testen ook ondersteunende processen bekeken zoals projectmanagement, kwaliteitsbeheersing en configuratiebeheer. In het bijzonder wordt ook gekeken naar de algemene managementpraktijken, die bijvoorbeeld ook de relatie met klanten en gebruikers, omgang met personeel (taakverdeling, scholing) en kwaliteitszorg omvatten.


27

SPICE SPICE (Software Process Improvement and Capability dEtermination) is een internationale standaard die ontwikkeld is met als doelstelling standaardisatie van softwareproces-assessment en -verbetering te bereiken. Deze standaard wordt ontwikkeld binnen het ISO-kader en komt beschikbaar als ISO 15504. De standaard is goedgekeurd binnen de formele kaders van ISO. In zijn uiteindelijke vorm zal ISO 15504 bestaan uit negen documenten, zie hiervoor Figuur 3.3.

Figuur 3.3 De 9 documenten van ISO 15504

PRINCE2 PRINCE2 (PRojects IN Controlled Environments) is een algemene project management methode, dat zich richt op de managementaspecten (Organisatie, Planning en Controle) van een project en scheidt deze aspecten van de specialistische taken voor het opleveren van de producten voor de organisatie (waaronder producten geleverd door derden). Gedurende de gehele looptijd van het project richt PRINCE2 zich op de rechtvaardiging van het project. In Figuur 3.4 staat een overzicht van de procesarchitectuur van PRINCE2.


28

Figuur 3.4 Procesarchitectuur PRINCE2

De belangrijkste elementen van PRINCE2 zijn: • de methode is procesgeoriënteerd en gericht op een zakelijke rechtvaardiging vanuit de staande organisatie; • er is een gedefinieerde organisatiestructuur voor het projectmanagement team; • de methode kent een op producten gebaseerde benadering van planning; • de methode legt de nadruk op de onderverdeling van projecten in beheersbare en controleerbare fasen; • de methode is flexibel en kan in elk soort omgeving gebruikt worden voor elk type project. Information Services Procurement Library (ISPL) ISPL is een library van ‘best practices’ voor het aanbesteden en doen realiseren van ICT-services door een externe ICT-dienstverlener of de eigen automatiseringsafdeling. Essentie is dat goede afspraken worden gemaakt tussen klant en leverancier, die zijn gebaseerd op een gedegen risicoanalyse van zowel de situatie van de klant als die van de leverancier. Deze methodiek vormt een integraal kader voor het inkopen, aanbesteden en outsourcen van IT producten en diensten. ISPL betreft de volgende onderwerpen: • Definitie van een acquisitie strategie • Management c.q. begeleiding van een tenderproces • Opzetten van een systeem of service delivery planning (definiëren van mijlpalen en beslispunten) • Monitoren van de uitvoering van contracten • Beheer van kosten en planning • Beheersing van risico’s

Voordelen ISPL voor klanten • Duidelijker formulering van requirements • Verbetering van risicomanagement • Begeleiding bij het kiezen van de passende acquisitiebenadering voor


29

Voordelen ISPL voor leveranciers • Een beter begrip van de behoeften van de klant • Een duidelijker zicht op de service of het systeem van de klant • Verbeterd risicomanagement m.b.t.

• • • • • • •

specifieke situaties Een beter begrip en beoordeling van de voorstellen/offertes van de leverancier Eenvoudiger beheersing van de ambities Adequate informatie om de kosten te beheersen Vermijden van een lock-in aan een specifieke leverancier of methode Beter beslissingsproces gerelateerd aan juiste set van producties (deliverables) Gemakkelijker acceptatie van systemen door een betere definitie van de requirements en de planning Verbetering contractmanagement

3.1.2

• • • • •

IT-projecten en services Passende en adequate benadering voor het leveren van een service en het uitvoeren van projecten Eenvoudiger om commitment van de klant te krijgen bij belangrijke ontwerpbeslissingen Eenvoudiger acceptatie van systemen, door een betere definitie van de requirements en planning Adequate informatie om de kosten te beheersen Verbetering contractmanagement

Product

Als over kwaliteit van een softwareproduct gesproken wordt, dan doelt men daarbij vaak op de geboden functionaliteit en het ontbreken van fouten na oplevering van het product.Vaak blijken dit niet de eigenschappen te zijn die voor gebruikers de kwaliteit van de software bepalen. Een voorwaarde daarbij is dat beide partijen weten wat eigenschappen als gebruiksvriendelijkheid, de beschikbaarheid en/of het tijdgedrag. betekenen. Er is behoefte aan een begrippenkader voor specificatie en validatie van kwaliteitseigenschappen van softwareproducten. EIA/IEEE J-STD-016 EIA/IEEE J-STD-016 1995 is een raamwerk voor het software ontwikkel proces (planning en engineering), één van de primaire life cycle processen in de IEEE/EIA 12207. Het kan gedurende de gehele life cycle (levenscyclus) van een systeem worden toegepast. Het stelt uniforme eisen aan inkoop, ontwikkeling, wijziging en documentatie van software. Het definieert standaard terminologie en het stelt activiteiten, taken en producten voor een software ontwikkel- of onderhoudsproject vast Het kan worden toegepast op zowel applicatie software als op operating systeemsoftware, software in firmware, herbruikbare software, software ontwikkeltools. De activiteiten in de standaard vormen een samenhangende set, voldoende voor een groot en complex project. Maar de standaard moet wel toegesneden worden voor elk project, door in de overeenkomst tussen leverancier en klant te specificeren welke bepalingen van kracht zijn. De standaard is onafhankelijk van een bepaalde methodologie, zodat de klant het product kan specificeren en de leverancier technologisch creatief en innovatief kan zijn. De activiteiten geven aan wát gedaan moet worden, maar niet hóe ze gedaan moeten worden. De keuze voor een life cycle model is vrij, de standaard geeft wel de bouwstenen aan. De keuze voor een ontwerpen programmeertaal is vrij. De standaard kan zowel intern een organisatie als contractueel tussen twee partijen worden gebruikt. De standaard maakt onderscheid tussen eisen voor een product en het ontwerp van het product, zodat de klant krijgt wat hij wil en de leverancier gebruik kan maken van kostenbesparende keuzes in het ontwerp. ISO 9126 In de huidige ISO 9126 (‘kwaliteitseigenschappen en richtlijnen voor hun gebruik’) worden definities van kwaliteitseigenschappen gegeven. In deze norm


30

worden zes eigenschappen gedefinieerd, en in de appendix van de norm wordt voor elke eigenschap een aantal deeleigenschappen gedefinieerd. In het kader van QUINT (Quality in Information Technology) is door SERC in samenwerking met een aantal partijen gewerkt aan een begrippenkader voor kwaliteit van softwareproducten. QUINT heeft geresulteerd in een uitbreiding van het kwaliteitsmodel zoals dat in ISO 9126 is beschreven. Figuur 3.5 geeft een overzicht van de hiërarchie van kwaliteitseigenschappen.

Figuur 3.5 Kwaliteitseigenschappen van ISO 9126 Naast de uitbreiding met een aantal eigenschappen zijn indicatoren, meetschalen en meetvoorschriften toegevoegd. Deze blijken in de praktijk de handvatten te vormen waarmee specificatie en validatie van softwareeigenschappen mogelijk worden. ITIL De kwaliteiten van een product worden niet alle bepaald door het product zelf, maar ook door de services die bij dat product worden geleverd. In dat kader wordt hier ITIL (IT Infrastructure Library) genoemd. ITIL bestaat uit een verzameling handboeken waarin de praktijk van IT-servicemanagement wordt behandeld. De beheerprocessen van ITIL Service Management worden verdeeld in: • Service Delivery Processen, gericht op de tactische planning van de IT dienstverlening: Service Level beheer, Kostenbeheer, Capaciteitsbeheer, Beschikbaarheidbeheer en Uitwijkplanning; • Service Support processen, gericht op de operationele planning: Configuratiebeheer, Wijzigingsbeheer, Software Control & Distributie, Incidentbeheer en Probleembeheer 3.1.3

People

P-CMM Naast het CMM heeft het SEI ook het People-CMM (ook wel P-CMM) ontwikkeld. Dit is een met CMM vergelijkbaar raamwerk dat zich richt op het ontwikkelen en managen van kennis, ervaringen en motivatie van de werknemers in de organisatie. Net als bij CMM wordt de volwassenheid van de


31

organisatie ten aanzien van human resource management in kaart gebracht en worden prioriteiten voor verbetering aangegeven. PSP Naast verbeteractiviteiten op het gebied van het softwareontwikkelproces en het softwareproduct ontstaat steeds meer aandacht voor verbetering van de capaciteiten van de individuele softwareontwikkelaar. Vooral het PSP (personal software process) richt zich hierop. PSP brengt structuur aan in het ontwikkelen van programmatuur door o.a. beschrijving van het software-ontwikkelproces, éénduidige procedures om haalbare afspraken te maken, hoe omgaan met definitie van eisen, de te leveren kwaliteit en bijbehorende planning, hoe omgaan met beschrijven van testen, schrijven van rapporten, etc. TSP Team Software Process (TSP). Na CMM voor de gehele softwareontwikkelende organisatie en PSP voor de individuele software engineer, is dit het derde (tussenliggende) niveau waarop processen in kaart worden gebracht en verbeterd. TSP kent vier fasen: Requirements, Design, Implementation en Test. TSP projecten kunnen in elke fase starten of eindigen. De TSP fasen overlappen elkaar. De methode toont hoe het concept van integrale projectteams op ontwikkeling van software-intensieve systemen kan worden toegepast. De teams krijgen een beeld van het proces met heldere doelen, teamrollen, risicomanagement en de methode levert een compleet en grondig teamplan. Na de start levert de methode een gedefinieerd, bemeten proces voor management, tracking en rapportage van het team. 3.1.4

Performance

Voor softwareontwikkeling moeten onder het motto ‘meten is weten’ metrieken worden gebruikt om inzicht in het ontwikkelproces te verkrijgen en om het te kunnen besturen op basis van die metingen. GQM Het GQM (goal question metric)-paradigma komt hieraan tegemoet door een gestructureerde aanpak voor introductie van een metriekenprogramma. Daarbij worden eerst de doelen bepaald ten aanzien van het softwareontwikkelproces en de daaruit voortkomende producten. Die doelen worden verfijnd in een aantal vragen en deze worden uitgewerkt in metrieken die antwoord moeten geven op de gestelde vragen. Productiviteit Op de markt verschijnen steeds meer commerciële tools waarmee men de productiviteit van een softwareontwikkelende organisatie kan bepalen.Van softwareontwikkelprojecten worden diverse data verzameld: de benodigde capaciteit, de doorlooptijd, de grootte van het ontwikkelde product (in termen van coderegels of functiepunten), de kwaliteit van het product (in termen van het aantal ontdekte fouten tijdens ontwikkeling en/of na oplevering) en een aantal karakteristieken van het project (bijvoorbeeld de ontwikkelomgeving en de kennis en ervaring van het ontwikkelteam).Verschillende tools bevatten een uitgebreide database met gegevens van reële projecten. Referentie: “Kwaliteitszorg van softwareontwikkeling”, Een overzicht van de belangrijkste ontwikkelingen”, dr. P.R.H. Hendriks, informatie november 2000. 3.2 Leveranciers

Hier worden een aantal instituten en samenwerkingsverbanden besproken die tevens leverancier zijn van kennis en/of methoden en technieken m.b.t. kwaliteitszorg.


32

3.2.1

Internationaal

Software Engineering Institute Het Software Engineering Institute (www.sei.cmu.edu) van de Carnegie Mellon University is een toonaangevend instituut in de Verenigde Staten en daarbuiten. SEI stelt zich ten doel: to provide leadership in software engineering and in the transition of new software engineering technology into practice. Hoofdsponsor is het Amerikaanse Ministerie van Defensie. Belangrijkste werkvelden: • (Software) Management Practices: CMM en CMMI zijn door het SEI ontwikkeld. Daarnaast heeft SEI het IDEAL-model ontwikkeld, dat in meer algemene zin een procesverbeteringscyclus beschrijft. SEI reikt jaarlijks in samenwerking met de IEEE Computer Society de Award for Software Process Achievement uit. • Engineering Practices, onder meer o The COTS-Based Systems Initiative: provides techniques for assembling and evolving software-intensive systems based on commercially available software components. o Personal Software Process: routinely produce work on schedule with reduced development time and significantly reduced numbers of defects in delivered code. o Team Software Process: help integrated engineering teams more effectively develop software-intensive products. This process method addresses many of the current problems of developing softwareintensive products and shows teams and their management explicitly how to address them. o Open Systems approach: efficiently acquire and maintain high-quality systems that are technically up-to-date. • Technology Adoption: ”the SEI helps software organizations to become more effective at selecting and adopting improved management and technical practices. Explore the topics listed on the left for more information about accelerating the transition of software engineering improvements into practice.” Andere relevante instituten in de Verenigde Staten: • ANSI (American National Standards Institute) • IEEE (Institute of Electrical and Electronics Engineers), heeft ook vele leden buiten de Verenigde Staten. European Foundation for Quality Management De in Eindhoven gevestigde European Foundation for Quality Management (www.efqm.org) is in 1988 opgericht door grote bedrijven met steun van de Europese Commissie. In 1991 introduceerde EFQM het EFQM Excellence Model, op basis waarvan jaarlijks een European Quality Award wordt uitgereikt. 3.2.2

Nationaal

Instituut Nederlandse Kwaliteit Het INK is een stichting met als doelstelling het verhogen van de kwaliteit van de bedrijfsvoering met behulp van het INK-managementmodel, een Nederlandse vertaling van het EFQM Excellence Model. Dit model wordt inmiddels door het management van honderden bedrijven, instellingen en overheidsorganisaties in Nederland gebruikt; zowel in grote bedrijven als in MKB en zowel in profit als in non-profit omgevingen. Het INK is in 1991 opgericht op initiatief van het Ministerie van Economische Zaken. Software Engineering Research Centre Het Software Engineering Research Centre is een kenniscentrum ter verbetering van de software engineering in Nederland. SERC is in 1987 opgericht als onderdeel van Stimulerings Projectteam Informaticaonderzoek, SPIN, met als


33

doel het verhogen van het kennisniveau op het gebied van software engineering in Nederland. In 1992 is dit door overheid en bedrijfsleven gesponsorde programma beëindigd en is SERC als onafhankelijke stichting verder gegaan, die zich onder meer richt op softwarekwaliteit. Onderzoek vindt plaats voor marktpartijen, maar SERC investeert ook in eigen onderzoeksactiviteiten, zoals het uitvoeren van interne onderzoeksprojecten en state-of-the-art verkenningen. Onderzoek vindt vaak plaats in samenwerking met anderen, zoals met de diverse informaticagroepen bij universiteiten of met onderzoeksafdelingen van bedrijven. SERC organiseert regelmatig opleidingen en workshops.


34

4 Stand van zaken binnen Rijkswaterstaat 4.1 Context 4.1.1

Systeemontwikkeling binnen V&W toegespitst op RWS

Systeemontwikkeling binnen V&W toegespitst op de situatie binnen RWS is in een aantal aparte groepen te verdelen, te weten: Ontwikkeling V&W brede systemen Het betreft hier voornamelijk de systemen die specifiek voor de bedrijfsvoering binnen V&W worden ontwikkeld. Denk hierbij aan een personeelsinformatiesysteem, een financieel systeem, e.d.. Deze systemen worden in principe ontwikkeld door het onderdeel van V&W dat de meeste materiekennis heeft. Er wordt (bij het ontbreken van een eigen afdeling voor systeemontwikkeling) gebruik gemaakt van externe bedrijven voor de ontwikkeling. Kwaliteitszorg is sterk afhankelijk van de kwaliteit van deze bedrijven (met name op het gebied van hun interne kwaliteitszorg). Ontwikkeling RWS brede systemen Het betreft hier voornamelijk de systemen die specifiek voor de taakuitvoering respectievelijk de bedrijfsvoering van RWS worden ontwikkeld of systemen die door meerdere diensten van RWS gebruikt worden (b.v. lodingsystemen, meetnetsystemen, verkeerssystemen). Deze systemen worden in principe ontwikkeld door het onderdeel van RWS dat de meeste materiekennis heeft (vaak een specialistische dienst) of door een voortrekkende dienst, in geval van samenwerkingsprojecten tussen verschillende diensten (bijv. ontwikkeling Rijkswaterstaat Meetnet Infrastructuur (RMI): directie Zeeland namens vijf directies van RWS). Ontwikkeling specifieke systemen binnen een directie/dienst van RWS Het betreft hier systemen die specifiek voor de taakuitvoering van een bepaalde directie/dienst worden ontwikkeld. Deze systemen worden in principe door de directie/dienst zelf ontwikkeld of in opdracht van de directie/dienst door een specialistische dienst ontwikkeld. Uit bovenstaande driedeling valt op te maken dat er op diverse plaatsen binnen V&W respectievelijk RWS systemen worden ontwikkeld. De mate waarin “Kwaliteitszorg voor systeemontwikkeling” een rol speelt is sterk afhankelijk van de volgende twee punten : 1. de wijze waarop de systeemontwikkeling binnen een dienst(onderdeel) georganiseerd is 2. de kennis en ervaring binnen een dienst(onderdeel) op het gebied van systeemontwikkeling (wat weer mede afhankelijk is van de frequentie waarmee systemen ontwikkeld worden) Ad 1, “de wijze waarop de systeemontwikkeling binnen een dienst(onderdeel) georganiseerd is” Er zijn diensten van RWS waar de ontwikkeling van systemen (met name op het gebied van de technische automatisering) een belangrijke rol speelt. Voor deze diensten (vaak regionale directies) zijn deze systemen cruciaal voor de taakuitvoering. Deze diensten hebben dan ook bijna altijd een afdeling die specifiek voor de ontwikkeling van (geautomatiseerde) systemen is opgezet. Een paar voorbeelden: • Directie Zeeland (meetnet, Hydro Meteo Centrum Zeeland, Stormvloedkering Oosterschelde (SVKO)) • Directie Noordzee (meetnet, Hydro Meteo Centrum Rijnmond, lodingsysteem, baggerinformatiesysteem)


35

•

RIKZ (Monitoring Systeem Water, systemen van de Stormvloed waarschuwingsdienst (SVSD), database t.b.v. onderzoek en trends)

De werkwijze is vaak als volgt: Op basis van een door de dienst geformuleerd eisenpakket wordt een opdracht (vaak met een vaste prijs en vastgestelde opleverdatum) onder intensieve begeleiding vanuit RWS aan het bedrijfsleven gegeven. Bedrijven dienen voldoende gekwalificeerd te zijn. Een belangrijk onderdeel is een werkwijze van de bedrijven die voldoet aan de ISO 9001 norm. Het bedrijf wordt verantwoordelijk gesteld voor het opleveren van een bedrijfsvaardig systeem. Een bedrijfsvaardig systeem is een systeem dat aantoonbaar aan alle gestelde eisen voldoet, direct bruikbaar is door de RWS dienst en wordt opgeleverd inclusief alle benodigde documentatie. Vaak mogen de aanbieders voor de opdracht hun eigen invulling geven van het aspect “Kwaliteitszorg”. Bij veel projecten wordt deze invulling tegenwoordig als beoordelingscriterium meegewogen. Dit meewegen is echter niet gestandaardiseerd binnen RWS. Ad 2, “de kennis en ervaring binnen een dienst(onderdeel) op het gebied van systeemontwikkeling (wat weer mede afhankelijk is van de frequentie waarmee systemen ontwikkeld worden)” In het kader van het aspect “Kwaliteitszorg voor systeemontwikkeling” is het onderstaande van belang: • De afgelopen jaren is systeemontwikkeling op managementniveau erg onderbelicht geweest. De schrikbeelden (de ontwikkeling van een systeem is altijd duurder dan gedacht, de ontwikkeling duurt altijd langer dan gepland en het ontwikkelde systeem doet niet wat het zou moeten doen) zitten er goed in en worden regelmatig weer bevestigd door projecten binnen RWS die een te optimistisch beeld richting management schetsen en daarna fors moeten corrigeren. • RWS heeft moeite om ervaren systeemontwikkelaars aan te trekken en te behouden. Een trend die de afgelopen jaren binnen RWS zichtbaar is geweest, is dat ervaren mensen op het gebied van systeemontwikkeling naar het bedrijfsleven vertrokken zijn en dat hun plaats werd ingenomen door onervaren mensen. Tevens is door het verminderen van budgetten bij de regionale directies merkbaar dat de ervaring terugloopt doordat er minder ontwikkelingen plaatsvinden. Dit heeft erin geresulteerd dat veel kennis ten aanzien van kwaliteitszorg binnen RWS is weggevloeid en dat het dus voorkomt dat het wiel opnieuw uitgevonden wordt. 4.1.2

Pilots

De systemen die worden gebruikt bij pilots kennen over het algemeen een zeer korte ontwikkelperiode. Tijdens deze periode wordt voornamelijk een zeer specifiek doel, bijvoorbeeld een specifieke functie, nagestreefd. Hierbij zijn de eisen ten aanzien van de kwaliteitsborging voornamelijk gericht op ‘doet het wat het moet doen’ en niet zozeer op langdurig gebruik. De huidige praktijk laat zien dat er na de pilotfase een evaluatie plaatsvindt op het specifieke doel waartoe de pilot heeft gediend. Hierbij wordt vaak vergeten het prototype te ontmantelen en uit de praktijksituatie weg te halen. Vervolgens blijkt het onderdeel te zijn geworden van de standaard verkeerssystemen die RWS beheert terwijl het ontwikkeltraject van dit prototype op andere aspecten was geoptimaliseerd dan operationele inzetbaarheid. Het pilotsysteem wordt dan operationeel ingezet terwijl het daar expliciet niet voor ontwikkeld was. Gevolg : hoge beheerkosten. Er dient derhalve nadrukkelijk onderscheid te worden gemaakt tussen pilots (met prototypen) en kwalitatief slecht ontwikkelde systemen. Bij pilots / prototypen is sprake van een kwalitatief goed systeem met (bewust gekozen) beperkte functionaliteit voor het opdoen van kennis of (leer)ervaring. Bij kwalitatief slecht ontwikkelde systemen (die soms onder de noemer pilotsysteem of prototype gebracht worden) is geen sprake van professionele systeemontwikkeling waardoor deze systemen niet of nauwelijks beheerd


36

kunnen worden en niet betrouwbaar functioneren. De kosten van beheer en onderhoud van dergelijke systemen zijn vaak buitensporig hoog. De kwaliteitszorg voor systeemontwikkeling waar in dit rapport over wordt geschreven zal aan dit aspect van systeemontwikkeling, binnen de Rijkswaterstaat, aandacht moeten geven. Als dit op de juiste wijze wordt onderkend zal het ook binnen de mogelijkheden gaan passen om hier adequaat nu en in de toekomst mee om te gaan. De uitkomst van de pilot-evaluatie is input voor het (verankerde) systeemontwikkelingtraject waar een kwaliteitsborgingmethode aan ten grondslag ligt. Het prototype zelf wordt ontmanteld en uit de praktijkomgeving gehaald. Mogelijk zijn onderdelen van het prototype goed te gebruiken in een latere fase waarmee de gevraagde snelheid van realisatie van het uiteindelijke systeem bereikt kan worden.

4.2 Inventarisatie

Voor dit rapport is een beperkte interviewronde binnen de AVV en de MD uitgevoerd. Het is de beleving van de geïnterviewden hoe kwaliteitszorg bij systeemontwikkeling plaatsvindt. 4.2.1

Methoden van kwaliteitszorg bij systeemontwikkeling binnen AVV

Onderstaand overzicht geeft een overzicht van kwaliteitszorg zoals die per afdeling binnen IB gehanteerd wordt en van de hulpmiddelen die hierbij worden gebruikt. BI en VM worden als geheel belicht. Afdeling IBA Er zijn bij IBA geen kwaliteitssystemen of methodieken in gebruik zoals ze in hoofdstuk 3 zijn omschreven. Er worden wel bepaalde algemeen binnen AVV toegepaste werkwijzen gehanteerd waarmee kwaliteitsborging plaatsvindt, zoals bijvoorbeeld de richtlijnen voor de Administratieve Organisatie (AO). Afdeling IBW De opdrachtverlening voor softwareontwikkeling (software wordt níet zelf ontwikkeld tenzij er geen financiën zijn) bij modellen en regeltechnische oplossingen gaat gepaard met een overeenkomst waarin is opgenomen wat bij (maatwerk) programmatuurontwikkeling door de opdrachtnemer geleverd moet worden. Dit beschrijft begrippen die van toepassing verklaard kunnen worden, zoals: • Maatwerkprogrammatuur, Systeemprogrammatuur, Hulpprogrammatuur; • programma van eisen; • functionele specificatie; • technisch ontwerp; • apparatuur; • documentatie; • materialen; • implementatie; • conversie; • acceptatietest, gebrek, acceptatie. In de praktijk blijkt het niet altijd noodzakelijk om alle hierboven beschreven onderdelen in een opdracht te hanteren. Dit hangt samen met de complexiteit van de opdracht. Praktisch kan dit bijvoorbeeld zijn: • gebruikerseisen; • functionele specificatie; • technisch ontwerp; • testplan, testscenario’s; • uitgevoerde testen, incidentmeldingen, voorgestelde oplossingen;


37

• documentatie; • acceptatietest, acceptatierapport/formulier. Deze onderdelen zijn tussenproducten waar de opdrachtgever zijn/haar akkoord aan moet geven voordat de opdrachtnemer verder kan. Afhankelijk van de complexiteit van de opdracht kunnen nieuwe inzichten samen met de opdrachtnemer worden verwerkt tot aanvullende/nieuwe eisen. Afdeling IBI Bij IBI wordt ten behoeve van kwaliteitszorg voor systeemontwikkeling gebruik gemaakt van : • J-STD-016 (documentatie standaard). • CMM/RM : user requirements management and engineering (ook in kader van SSS uit de J-STD-016) wordt als methode steeds meer toegepast. Stelt ook eisen aan de omgeving van een project. Voorbeelden: BOSS off-line, koppeling Paramics-MTM • CMM/PP, PT&O: Tracking and Oversight wordt nu opgebouwd bijvoorbeeld voor Saviera • CMM/CM : Change control and configuration control wordt geïmplementeerd bijvoorbeeld voor Saviera • PRINCE2 wordt door een aantal mensen gebruikt voor projectbeheersing. Met deze aanpak wordt gewerkt aan kwaliteit bij het vastleggen van eisen, het beheren van eisen vastgelegd in documenten, het plannen van projecten, het volgen van projecten tijdens uitvoering. Afdeling IBB Principes van ITIL worden gehanteerd. Bovendien zijn er voorziene procesverbeteringen bij IBB met betrekking tot : • Reverse engineering van Monitoring naar documentatie conform de J-STD-016; • Procesbeschrijving van functioneel beheer en van applicatiebeheer (procedureboek systeemhouderschap AVV/IBB ). Dit model is gebaseerd op het FATO model van prof. Van Looijen (TU Delft). Dit is een eerste stap op weg naar een ISO 9002 certificering; • Volgende stap is het proces te verbeteren met het door Pink Roccade ontwikkelde ASL (Application Service Library); • De workshop “Betrouwbaar Beheer”. Hier worden ook aanbevelingen gedaan voor de verbetering van het ontwikkelen beheerproces van applicaties, waarbij de system life cycle een grote rol speelt. • Er is een start gemaakt met de inrichting van het bewakingsproces m.b.t. de nauwkeurigheid van gegevensinwinning (monitoring data die betrekking heeft op beheer). Dit proces moet input leveren aan het proces wijzigingsbeheer. Hoofdafdeling BI Bij BI wordt gewerkt met ITIL. Er is een algemeen kwaliteitssysteem opgezet dat je kunt omschrijven als een variant op “integrale kwaliteitszorg” en Total Quality Management (IKZ en TQM). Bovendien ontwikkelt BI programmatuur/software met CDM, de Custom Development Method van Oracle; deze methode sluit goed aan bij de Oracle ontwikkeltools die BI gebruikt. Hoofdafdeling VM Er wordt binnen VM weliswaar geen kwaliteitszorgsysteem gehanteerd, maar in elk geval is voor documentatie van het Overdraagbaar GroeiModel (OGM), de “Simulatiemodellen Natte Waterstaat” (SIMONA) normering met succes toegepast.


38

De SIMONA-normering is in het kader van het SIMONA-project opgesteld in opdracht van het RIKZ en omvat : • Richtlijnen voor het schrijven van Fortran77 programmacode (rapport nr. 92-07, versie 2.2, februari 2000) • Een aanvulling op de RWS C norm (rapport nr. 95-03, versie 2.1, februari 2000) • Een norm voor opbouw en opmaak van een gebruikershandleiding (rapport nr. 92-08, versie 2.1 oktober 1998) • Een norm voor systeemdocumentatie (rapport nr. 91-08, versie 990208). Deze geeft een verplichte hoofdstukindeling voor de documenten alsmede een checklist van onderwerpen die in aanmerking komen voor documentatie Verder is er in opdracht van Provincie en RD Noord Brabant, ter voorbereiding op hun NRM 3.0 (Nieuw Regionaal Model) een document opgesteld getiteld “procesbeheersing voor een hogere kwaliteit”. De genoemde methoden zijn allemaal geen formele standaarden maar wellicht zijn ze te koppelen aan bepaalde standaarden voor kwaliteitszorg. Er staat al enige tijd een actie om voor het NRM te komen tot een vorm van kwaliteitsborging al was het alleen maar in de vorm van opleverprotocollen voor alle eind- en tussenproducten die in een NRM traject geproduceerd worden. Ook een document met begrippen en definities zou daar bij kunnen horen. Als methodiek voor kwaliteitszorg bij VM wordt ook het handboek “Good Modelling Practice” gebruikt . Dit handboek beschrijft de verschillende stappen/onderdelen die kunnen worden toegepast/ onderscheiden bij het ontwikkelen van modellen. Voorbeelden van modellen zijn het eerder genoemde Nieuw Regionaal Model, het Landelijk Model Systeem (een zeer complex systeem wat bij beleidsprognoses wordt toegepast.) 4.2.2

Methoden van kwaliteitszorg bij systeemontwikkeling binnen MD

Een inventarisatie bij de hoofdafdeling IB van de Meetkundige Dienst levert het volgende beeld op: Afdeling IBV (ICT Verkeer en Vervoer) • Gebruik van ITIL bij de Vicnet Beheer Organisatie en SPITS • PRINCE2 wordt toegepast bij alle projecten. Het gebruik is niet verplicht gesteld, maar het wordt opgepakt door het merendeel van de projectleiders. De huidige status is dat er bij de opstart van een project veel gebruik wordt gemaakt van PRINCE2 procedures en templates voor projectvoorstellen en projectplannen (project initiatie document). De beheersing van een project conform PRINCE2 is een volgende stap, waar de afdeling momenteel middenin zit. De Ambitie is om grote projecten conform PRINCE2 uit te voeren en om in de toekomst bij inhuur en uitbestedingen PRINCE2 verplicht te stellen. Dit kan alleen als je de methoden zelf goed beheerst en daarom wordt hiermee de komende twee jaren ervaring opgedaan. • Een groot systeemontwikkelingtraject waarbij de afdeling IBV is betrokken is het project Vanessa. Formeel is dit een project van de RWS Directie NoordHolland, waarbij MD, AVV en BD en diverse regionale directies zijn betrokken. Binnen dit project worden o.a. de volgende methoden en technieken gebruikt : o J-STD-016; deze documentatie standaard is voor het hele project verplicht gesteld. Er zijn hier en daar aanpassingen gedaan specifiek voor Vanessa. Er zijn bijvoorbeeld diverse handleidingen samengevoegd tot 1 document. o UML; deze notatietechniek wordt door de meeste leveranciers die werken voor het project gebruikt. Het valt op dat het gebruik van UML


39

o o

in combinatie met de J-STD-016 standaard nieuw is voor alle leveranciers en dat iedereen hier een andere invulling aan geeft. Voor de marktbenadering is geprobeerd de methode ISPL te introduceren. Na diverse cursussen en begeleiding van een extern bedrijf is besloten om ISPL niet toe te passen binnen Vanessa. Het SERC (zie hoofdstuk 3) voert reviews uit op de documentatie en source-code. Invalshoek is met name de onderhoudbaarheid van het systeem. Controles vinden plaats op ontwerpbeslissingen, gecontroleerd wordt of ze duidelijk gemotiveerd zijn tot het bepalen van de complexiteit van een software-component. Tijdens een van deze reviews heeft het SERC geconstateerd dat de J-STD-016 standaard minder geschikt is voor het geven van overzicht over en inzicht in de architectuur en het ontwerp van het systeem. Dit komt doordat de architectuur verspreid beschreven is over een groot aantal documenten en de documenten gericht zijn op een system-breakdown structure.

Afdeling IBW (ICT Water) • Bij IBW worden weinig systemen ontwikkeld. Tot nu toe zijn er geen specifieke methoden toegepast • PRINCE2 voor projectmanagement (zie bij IBV) wordt toegepast. Het bovenstaande overzicht laat een divers beeld zien van de verschillende toegepaste methoden.

4.3 Toekomstverwachtingen 4.3.1

Met betrekking tot het vakgebied

RWS speelt geen rol in het veld rond kwaliteitszorg voor systeemontwikkeling. Systeemontwikkeling op zichzelf is geen specialiteit van de organisatie; een voorhoederol op onderzoeksgebied is dan ook niet aan te bevelen. Het ligt meer voor de hand dat RWS zich zal positioneren als trendvolger. Voorlopig zijn voor RWS de twee belangrijkste trends: • Opkomst van INK als dominant managementmodel voor het beschrijven, analyseren en structureren van kwaliteitszorg in het algemeen in een organisatie. • Opkomst van CMM(I) als dominant groeimodel voor procesverbetering in de ICT-wereld (software- en systeemontwikkeling) 4.3.2

Met betrekking tot V&W en RWS

Ontwikkeling van systemen binnen V&W is een bovengemiddelde kostenpost. Dit komt mede door meervoudige ontwikkelingen en diverse mislukte projecten. De “Gideonsbende” heeft het probleem onderkend (veelheid aan soorten ICT binnen V&W; ontbreken van standaardisatie). Vanuit de gedachte dat de kosten verminderd moeten worden, zal de systeemontwikkeling binnen RWS onder druk komen te staan. Een aantal ontwikkelingen die binnen AVV/IBI al in gang zijn gezet, zullen waarschijnlijk RWS breed ingevoerd worden. Te denken valt aan: • Meer aandacht voor producten die “standaard” verkrijgbaar zijn dus minder “specials” • Meer aandacht voor kwaliteitszorg in brede zin van de RWS organisatie (kennis en ervaring personeel, gestructureerde werkwijze, kwaliteitszorg en mogelijk bij bepaalde diensten resp. dienstonderdelen de introductie van kwaliteitssystemen) Daarnaast zullen RWS breed een aantal zaken in de toekomst onvermijdelijk zijn, zoals:


40

• • •

•

• •


Duidelijk formuleren van toetsbare eisen die gesteld worden aan een systeem Duidelijker scheiding van verantwoordelijkheden tussen RWS en bedrijfsleven (zakelijker met elkaar omgaan) Bredere kijk op systemen. Bij de definitie van een systeem je niet beperken tot de (automatiserings)techniek maar ook de aspecten organisatie, werkwijze en mensen (gebruikers en beheerders) voldoende aandacht geven om een samenhangend geheel te verkrijgen dat aan de doelstelling gaat voldoen. Life cycle visie. Niet alleen kijken naar de ontwikkeling van systemen maar de totale life cycle (ontwikkelen, gebruiken, ontmantelen/vervangen) beschouwen. Bij de specificatie en het ontwerp van het systeem nadrukkelijk rekening houden met de gebruiksfase en de verwachte levensduur van een te ontwikkelen systeem. Life cycle beheer staat bij RWS nog in de kinderschoenen. In Bijlage: System life cycle: ontwikkeling en beheer is een visie geschetst hoe life cycle beheer binnen AVV ingevuld zou kunnen worden. Commitment en duidelijke aansturing van de systeemontwikkeling vanuit het management om de bedrijfsdoelen te bereiken. RWS krijgt in toenemende mate te maken met het snel behalen van zichtbare resultaten die echter wel dermate kwalitatief moeten zijn dat de systemen diverse jaren gebruikt kunnen worden. Om snel resultaat te bereiken zullen in een aantal gevallen pilots nodig zijn om de haalbaarheid en de wenselijkheid van bepaalde oplossingen te onderzoeken. De context waarbinnen RWS op het gebied van DVM-systeemontwikkeling opereert kent veel verschillende partijen. Onder andere de Nederlandse verkeers-industrie, regionale directies van Rijkswaterstaat, belangengroeperingen (bijvoorbeeld ANWB) en andere overheden (gemeenten en provincies). In potentie is dit een vruchtbare voedingsbodem voor nieuwe, innovatieve en verbeterde systemen. Er ontstaan voorstellen voor nieuwe systemen, daar komt bij de bouw van prototypen en natuurlijk de praktijk met pilot studies. De genoemde ontwikkelingen spelen op het rijkswegennet, het provinciaal en het gemeentelijk wegennet.

41

5 Aanbevelingen m.b.t. kwaliteitszorg systeemontwikkeling In de voorgaande hoofdstukken is een overzicht gegeven van onderwerpen waarin de leden van het Kenniscentrum Kwaliteitszorg voor Systeemontwikkeling zich in 2002 en begin 2003 hebben verdiept. Gewapend met deze kennis en ontwikkelingen beschouwend binnen Rijkswaterstaat en de specialistische diensten, bevelen we een aantal procesverbeteringen aan (zie: “Aanbevelingen m.b.t. implementatie”). Deze zouden in de loop van 2003 en 2004 kunnen worden geïmplementeerd, in het bijzonder bij de hoofdafdeling AVV/IB. Het Kenniscentrum is niet voornemens deze implementaties te trekken, maar is wel bereid als klankbordgroep te fungeren. Daarnaast zijn we onderwerpen tegengekomen waarvan we verwachten dat die in de komende jaren van belang gaan worden, maar waarover we op dit moment nog onvoldoende kennis in huis hebben om er ook praktisch mee aan de slag te gaan. Met betrekking tot deze onderwerpen bevelen wij aan dat het Kenniscentrum zich die kennis in de komende – pakweg – 1½ jaar eigen gaat maken (zie: “Aanbevelingen m.b.t. kennisverwerving”). Hieruit kunnen in de volgende versie van het State-of-the-Art-rapport aanbevelingen voor implementatie voortkomen. 5.1 Aanbevelingen m.b.t. implementatie van kwaliteitszorg

1.

Wij stellen voor om life cycle management voor systemen vorm te geven (zie Bijlage: System life cycle: ontwikkeling en beheer). Zeker in een tijd van financiële krapte is het van groot belang om scherp op het netvlies te hebben in welk stadium een systeem verkeert, om op basis daarvan kosteneffectieve acties te kunnen ondernemen. Daarbij komen vragen aan de orde als: loont het de moeite om in functionele uitbreiding te investeren? in hoeverre sluit het (nog) aan bij de behoeften van de gebruikers? kan de levenscyclus opgerekt worden? is het de beheerkosten waard? Deze en dergelijke vragen worden nu niet of nauwelijks gesteld en als ze al gesteld worden gebeurt er niet veel mee. De verantwoordelijkheid voor life cycle management zou kunnen worden belegd bij de Configuration Control Board van de Adviesgroep Verkeerssystemen, die het uitvoerende werk zal delegeren naar de betreffende systeemhouder.

2.

In relatie hiermee zouden de kosten van beheer zichtbaar gemaakt moeten worden. Dat kan op het niveau van een systeem, maar het is ook mogelijk dit door te vertalen naar gebruikers(-organisaties) middels notional charging1. Kosten worden een belangrijk sturingsinstrument voor het management van systemen.

3.

Het verdient aanbeveling om de werkwijze van systeemontwikkeling verder te standaardiseren binnen het DVM-domein, met de nadruk op projectmanagement en inkoop (in relatie met P-OG 212). Alleen op deze manier kan er beter inzicht ontstaan in de kosten van systeemontwikkeling, namelijk als de fasering van verschillende projecten vergelijkbaar is. Daarbij moeten reeds geïmplementeerde procesverbeteringen bestendigd worden.

1

Notional charging = kosten per gebruiker (directie, object, etc.) in beeld brengen alsof ze zouden worden doorberekend. 2 Professioneel Opdrachtgeverschap in de 21e eeuw (RWS-breed project)


42

5.2 Aanbevelingen m.b.t. kennisverwerving over kwaliteitszorg

1.

Om de kosten van systeemontwikkeling beter te kunnen overzien en beheersen is het wenselijk metrieken toe te passen. Een randvoorwaarde is dat projecten qua fasering en aanpak enigszins vergelijkbaar zijn (zie hierboven), maar ook zou het kenniscentrum zich de benodigde methodische kennis eigen moeten maken. Over metrieken wordt sinds tientallen jaren veel gepubliceerd, het gaat er uiteindelijk om dat we een selectie maken die op onze omstandigheden is toegesneden.

2.

Hoe verder met het Capability Maturity Model? Er zijn recentelijk diverse implementaties van CMM verschenen (o.a. CMM-Integrated). Het lijkt ons goed om hier meer van te weten en na te gaan welke het meest geëigend is voor onze organisatie. Daarnaast willen we kennisnemen van PSP en TSP (resp. People - en Team Software Process) om te bezien in hoeverre deze mens- resp. groepsgerichte benaderingen een aanvulling zouden kunnen vormen op het instrumentarium van systeemontwikkeling. Een en ander in relatie tot het INK-model.

3.

Prototyping en pilots. Binnen AVV worden regelmatig (verkeerskundige) pilots gehouden, bijvoorbeeld die met een dynamische maximumsnelheid op de A1 bij Apeldoorn. Daarnaast zijn er (meer ICT-geöriënteerde) prototypen, bijvoorbeeld het DENVER-systeem. Wat voor soorten prototypen bestaan er en wat zijn de toepassingsgebieden? Wanneer is het zinvol om van een applicatie een prototype te bouwen? Is het mogelijk een brug te slaan tussen (verkeerskundige) pilots en (ICT) prototypen, of is dat juist onverstandig? Hoe kan je op een beheerste manier van een prototype en/of pilot naar een productiesysteem overgaan? Kortom, hoe zou het traject van research & development in relatie tot DVM-systemen er uit kunnen zien?

5.3 Voortzetting Kenniscentrumactiviteiten

De leden van het kenniscentrum realiseren zich dat het budget voor DVMsysteemontwikkeling in de komende jaren zeer beperkt zal zijn. De kans is reëel aanwezig dat aan activiteiten die de systeemontwikkeling ondersteunen minder prioriteit zal worden toegekend. In dat geval heeft het ook weinig zin om een kenniscentrum op dit gebied te onderhouden. Alleen als de opdrachtgever (hoofd AVV/IB) expliciet vraagt om activiteiten uit te voeren c.q. producten te leveren - en in het voorgaande zijn daartoe suggesties gedaan – zal het kenniscentrum worden voortgezet. Het is ons inziens overigens noodzakelijk dat er ook in breder kader aan kwaliteitszorg wordt gewerkt, zoals op het niveau van de hoofdafdeling AVVIB.


43

6 Bijlage: System life cycle: ontwikkeling en beheer 6.1 Inleiding

Systemen worden ontwikkeld en geëxploiteerd. Daarmee is niets nieuws onder de zon. Er is meestal een instantie die het systeem ontwikkelt en een instantie die het systeem tijdens exploitatie beheert. Ontwikkeling is meestal projectmatig van aard en exploitatie (beheer) procesmatig. Ontwikkelkosten zijn ongeveer 30% van de totale exploitatiekosten. 6.1.1

Systeemontwikkeling in de praktijk

Zoals in de inleiding beschreven lijkt de wereld van de ICT overzichtelijk en eenvoudig. Maar helaas, de praktijk is meestal anders. Maar al te vaak worden systemen na ontwikkeling “over de schutting gegooid” naar de beheerafdeling. De beheerafdeling heeft dan niet de kennis, de capaciteit en de financiële middelen om het systeem adequaat te beheren. Bovendien worden zij vaak geconfronteerd met onduidelijke of onmeetbare systeemspecificaties ten aanzien van beschikbaarheid, betrouwbaarheid en performance. Het gevolg hiervan kan zijn dat het systeem niet aansluit bij de verwachtingen van de gebruikers en deze de zwarte Piet bij de beheerafdeling leggen. Dit heeft vaak kostbare wijzigingstrajecten tot gevolg om het systeem op meetbare eenduidige specificatie te krijgen. Voorbeeld meetbare en eenduidige specificatie van beschikbaarheid In veel systeemspecificaties staat dat het systeem voor 98% beschikbaar moet zijn. Bij deze eis zullen gebruiker en beheerders ieder een eigen perceptie hebben. De specificatie is dus niet voor iedereen eenduidig en ook niet meetbaar In onderstaande case wordt dit verduidelijkt met de dienst “Leeslamp”. Met een afnemer (gebruiker) van de dienst “Leeslamp” (een dienst, geleverd door een bepaalde instantie, die de afnemer van de dienst is staat stelt om op de afgesproken tijden een boek te kunnen lezen), wordt afgesproken dat de dienst 365 dagen per jaar van 1 jaar tussen 20:00 EN 23:00 uur (service periode) voor 98% beschikbaar is. Technisch gesproken wil dat dus zeggen dat de lamp over bijv. de maand november gemeten: 30 dagen x 3 uur x 98% = 88.2 uur heeft moeten kunnen branden tijdens de afgesproken service periode. Hiermee lijkt de specificatie duidelijk en meetbaar. De gebruiker heeft echter nog een ander belang, namelijk voldoende lichtopbrengst om te kunnen lezen. Branden alleen is dus niet voldoende. Als de lichtopbrengst namelijk zodanig is teruggelopen dat lezen onmogelijk wordt, dan zal hij de dienst “Leeslamp” ervaren als niet beschikbaar. Dit impliceert dat kwaliteit een onderdeel kan zijn van beschikbaarheid. We spreken dan niet meer van technische beschikbaarheid maar van functionele beschikbaarheid. Er wordt nu afgesproken dat, als de lichtopbrengst op 1 meter van de leeslamp zakt onder de 300 lux (onder deze lichtopbrengst is lezen niet meer mogelijk), de dienst “Leeslamp” niet meer beschikbaar is. Hiermee is technische beschikbaarheid veranderd in functionele beschikbaarheid en zal beter aansluiten bij de belevingswereld van de afnemer van de dienst en is bovendien een meetbare specificatie geworden.


44

In deze bijlage wordt getracht nadere uitwerking te geven aan een aantal kritieke succesfactoren die zijn benoemd in het eindrapport “Beheren met de kleine b”. Dit met als doel ontwikkeling en beheer beter op elkaar af te stemmen. Voor een beter begrip van deze bijlage is het belangrijk kennis te hebben van dit eindrapport. Opmerking: Deze bijlage is primair bedoeld voor de ontwikkeling en exploitatie van DVM systemen maar kan ook voor andere typen systemen als basis dienen. Definitie Systeem Een doelmatig geordend samenhangend geheel van bijbehorende dingen en hun onderdelen. (bron: Wolters handwoordenboek). Vertaald naar automatiseringssystemen geeft de volgende definitie een iets meer houvast: Een informatiesysteem is een samenwerkingsverband van ongelijksoortige componenten. (bron : ICT-zakboekje 1999) De bijbehorende systeemdocumentatie kan daaraan worden toegevoegd. 6.1.2

Relatie systeemontwikkeling en beheer bij greenfield projecten

De ontwikkeling van nieuwe systemen noemt men ook wel greenfield projecten. Er is een informatiebehoefte maar het systeem moet nog gebouwd worden. In principe worden DVM systemen bij de AVV ontwikkeld volgens het pijplijnmodel. Systeemontwikkeling zou je, als je dat zou vergelijken met het drie lagen model zoals is vastgelegd in de beleidsnotitie “Beheren met de kleine b”, het beste kunnen positioneren in de in Tabel 6.1 beschreven structuur. Fase Fase 1 Fase 2 Fase 3 Fase 4

Beschrijving rol in het ontwikkelproces (project) Verkeerskundig beleid en ontwikkeling regelstrategieën Definiëren van Verkeerskundige maatregelen en ontwikkeling regeltactieken Systeemontwerp, systeembouw, en acceptatie Systeemtest en Functioneel Beheer

Afdeling IBA

Niveau in “kleine b” Strategisch

IBW

Tactisch

IBI

Tactisch

IBB

Tactisch

Tabel 6.1 Om de problematiek, zoals omschreven in paragraaf 5.1.1, beheersbaarder te maken is het noodzakelijk dat de beheerafdeling (bij de AVV afdeling IBB) bij de ontwikkeling betrokken wordt. Belangrijkste doelen hierbij zijn: • toetsing op meetbare systeemspecificaties en beheerspecificaties; • het inrichten en implementeren van een beheerorganisatie; • het afsluiten van service level agreements met de gebruikersorganisatie; • het reserveren van de benodigde financiële middelen voor exploitatie; • het definiëren van toetsingscriteria voor het bepalen van de system life cycle. Deze toetsingscriteria zijn een belangrijk houvast bij het plannen van nieuwe releases van de software. De eerste vier punten zijn inmiddels redelijk ingeburgerd. Het laatste punt is echter van een andere orde. Waarom het noodzakelijk is dit kwaliteitsaspect te implementeren wordt hieronder uitgelegd.


45

6.2 System life cycle

Het is moeilijk aan te geven hoelang het verantwoord is een systeem te exploiteren en wanneer het moment is gekomen om nieuwe ontwikkelingen een kans te geven. Maar al te vaak zie je systemen die koste wat kost in de lucht worden gehouden, waarbij de onderhoudskosten de pan uit rijzen en het doel waarvoor het systeem is ontwikkeld veelal grotendeels achterhaald is. Omgekeerd gebeurt het ook dat nieuwe systemen worden ontwikkeld, terwijl met een betrekkelijk eenvoudige additionele wijziging op een bestaand systeem, de gevraagde functionaliteit kan worden geïmplementeerd. Als duidelijkheid wordt verschaft omtrent de system life cycle en de criteria die hieraan ten grondslag liggen is mogelijk ook de grens bepaald tussen exploitatie (beheer) en (nieuwe)systeemontwikkeling. Om te bepalen of een systeem aan het eind van zijn system life cycle is zijn er binnen de beheerprocessen een aantal aanpassingen noodzakelijk. Zowel binnen ITIL als in het FATO model van professor Looijen is omschreven hoe men de system life cycle bepaalt. Wil men binnen DVM beheer hier duidelijkheid over hebben dan is het noodzakelijk duidelijke afspraken worden gemaakt omtrent: 1. definitie van “system life cycle”; 2. wanneer wordt er getoetst of het eind van de system life cycle is bereikt; 3. toetsingscriteria voor het bepalen van het einde van de system life cycle; 4. wie toetsen er; 5. binnen welk beheerproces vindt dit plaats; 6. relaties met andere (beheer)processen; 7. wie is verantwoordelijk voor de toetsing en de resultaten; 8. hoe past dit in het beheerconcept “Beheren met de kleine b” 6.2.1

Definitie system life cycle

System life cycle is de periode tussen het moment dat waarop het informatiebeleid gestalte krijgt tot het moment waarop het systeem verdwijnt. (definitie uit: “Beheer van informatie systemen” van prof. dr. ir. M. Looijen vijfde druk). Deze definitie is wat lastig te hanteren, omdat het bij het begrip “informatie beleid” moeilijk is aan te geven wanneer dit start. Ook het moment van “verdwijnen” is voor meerdere uitleg vatbaar. Is dit afvoeren naar de domeinen, of uitschakelen, of het moment van verkeerskundig niet meer voldoen. Toch is het handig om binnen de wereld van dynamisch verkeersmanagement een eenduidig begrippenkader te hanteren. Om dit wat concreter te maken is de volgende definitie wellicht beter: De system life cycle voor DVM systemen is de periode vanaf het moment dat het strategisch management opdracht geeft een nieuw systeem te ontwikkelen, tot het moment waarop het systeem verdwijnt. 6.2.2

Wanneer wordt er getoetst

Het is vooraf natuurlijk gemakkelijk aan te geven wanneer de system life cycle start maar zeer moeilijk wanneer deze eindigt. Toch is het zinvol van tevoren na te denken over hoe lang een systeem moet voldoen, zodat men tijdens exploitatie rekening kan houden met tijdige vervanging. Richtlijn hierbij kan zijn de regelmaat waarin verkeerskundig beleid wordt getoetst. Is dit om de vier jaar, dan is het zinvol om na deze vier jaar een evaluatie uit te voeren of het systeem nog voldoet aan de verkeerskundige doelstelling. Een andere mogelijkheid is toetsing binnen het reguliere wijzigingsproces. Het wijzigingsproces zoals dat beschreven is in “Beheren met de kleine b” kent verschillende wijzigingscycli. Met deze cycli worden wijzigingstrajecten ingezet


46

die lopen over de verschillende beheerniveaus, strategisch, tactisch en operationeel. Deze worden aangeduid met cyclus 1, 2 en 3 (operationeel, tactisch en strategisch). Binnen zo’n cyclus is weer een onderverdeling mogelijk over de taakvelden, zuilen genoemd in “Beheren met de kleine b”. Deze zuilen zijn : verkeerskundig, Verkeersmanagement en ICT. Het is echter niet duidelijk wat de toetsingscriteria zijn om te komen tot het bepalen van de cyclus, wie er toetsen en wie de beslissing neemt. In het algemeen kun je dus zeggen dat, indien een wijziging binnen cyclus 3 noodzakelijk is, het einde van de system life cycle is bereikt. Er wordt dan een nieuw systeem ontwikkeld dat het oude zal vervangen. De ontwikkeling van het nieuwe systeem is een verantwoordelijkheid van de ontwikkelafdeling (IBI) Echter, cyclus 3 wijzigingen binnen de ICT zuil houden geen verkeerskundige / functionele aanpassing in. Het betreft echter wel een zeer grote wijziging (major changes), waarbij beslissingen op strategisch niveau noodzakelijk zijn, maar die binnen het wijzigingsproces kunnen worden uitgevoerd en onder verantwoordelijkheid van de beheerafdeling (cyclus 3b). Dit kan men “migratietrajecten” noemen, omdat de functionele specificatie niet wordt aangepast. Voorbeelden hiervan kunnen zijn: de migratie van VICnet, overstap naar een ander hardware platform etc. In figuur 6.1 zijn de zuilen en de wijzigingscycli zoals gedefinieerd binnen “Beheren met de kleine b” geprojecteerd op het pijplijnmodel zoals AVV/IB hanteert. VK zuil

VM zuil

ICT ZUIL

IBA Strategisch / tactisch beleid Regelstrategien

wijzigingen Cyclus 3b

Advies

Formeel Strategisch VM beleid

MD Toetsing aan Informatie beleid Opdrach t

Opdrach t IBW Maatregelen Regeltactieken

Management informatie

Advies Advies IBI Ontwikkeling acceptatie en invoering

IBI Systeem specificatie

IBB

IBB Systeemhouder

Functioneel en applicatiebeheer

Tactisch

Beleid

Evaluatie

SPA SPITS

Einde Life cycle

Technisch beheer

Opdracht

Nieuwe ontwikkel methoden

Overige wijzigingen Participatie

Figuur 6.1 Beheren kleine b + pijplijnmodel + AVB


47

Nee

Wijzigings proces

Operationeel

Advies

Informeel Strategisch VM beleid

Strategisch

Vernieuwing / vervanging Cyclus 3a Beleidsdirecties en AVV Strategisch VK beleid

6.2.3

Wie toetsen er

In iedere fase van de ontwikkeling en exploitatie van een systeem is er naast een tactische laag ook een strategische laag aanwezig, die beleidsmatig verantwoordelijk is. Hierbij onderscheiden we de beleidsdirecties (DGP en DGG) die verantwoordelijk zijn voor het landelijke verkeerskundig beleid en de wetmatige grondslag, het hoofdkantoor (Kennis en Ontwikkeling) voor het landelijke beleid op het gebied van Verkeersmanagement, de Regionale Directies voor het regionale beleid t.a.v. verkeersbeheersing en verkeersmanagement en de MD waar het gaat om het RWS brede ICT beleid. Het is belangrijk dat de strategische en tactische processen tijdens ontwikkeling en exploitatie goed op elkaar zijn afgestemd om duidelijkheid te hebben omtrent het besluitvormingsproces. Om een verantwoord besluit te kunnen nemen omtrent de status van een DVM systeem en het vervolgtraject is het noodzakelijk dat alle personen die een beslissende rol vervullen op strategisch, tactisch en operationeel niveau over de drie zuilen zoals de zijn bepaald in “Beheren met de kleine b” vertegenwoordigd zijn. In hoofdstuk 9 van het managementrapport Architectuur voor Verkeersbeheersing worden deze rollen beschreven. Nu is het waarschijnlijk onpraktisch alle rollen die hier zijn beschreven bij het evaluatietraject te betrekken. Het is beter een extractie te maken uit deze rollen en deze te typeren als “beslissers”en “adviseurs”. Het is ook mogelijk om de evaluatie te laten uitvoeren door de adviseurs die de resultaten van de evaluatie presenteren aan de beslissers. Het definiëren van beslissers in de huidige situatie is een moeilijke zaak. Dat komt omdat er onderscheid gemaakt kan worden in: • Lijnverantwoordelijken (functies) • Functioneel verantwoordelijken (rollen) Om een verantwoord onderscheid te kunnen maken zijn beiden hier omschreven als formele beslissers en informele beslissers. Formele beslissers (met lijnverantwoordelijkheid) • Directeur Kennis en Ontwikkeling van het Hoofdkantoor • (Hoofd)Afdelingshoofden (als gedelegeerden van de HID vertegenwoordigd in een Configuration Control Board); • HID’s Informele beslissers (met verantwoordelijkheid vanuit hun rol): • Beleidsverantwoordelijke voor het verkeerskundige deel van de beleidsdirectie (DGP en DGG); • Programma manager verkeersbeheersing; • College van Verkeersmanagers (RD’s en HK/U); • Adviesgroep verkeerssystemen; • Hoofden Verkeerscentrales; Wie beslissen is natuurlijk afhankelijk van het type wijziging. Bovenstaande beslissers dienen in ieder geval betrokken te worden bij wijzigingen op strategisch niveau. Kortom, als het advies is dat het bestaande systeem aan het eind van de system life cycle is en nieuwe ontwikkeling noodzakelijk is. Op het hoogste niveau is voor landelijke ontwikkelingen de Directeur Kennis en Ontwikkeling natuurlijk verantwoordelijk. Het is echter gebruikelijk dat deze verantwoordelijkheid wordt gedelegeerd naar de HID’s en afdelingshoofden. Deze kunnen als hoogst formeel beslissend orgaan zitting hebben in een Configuration Control Board. De informele beslissers zijn degenen die het advies het beste kunnen beoordelen. Zij kunnen zorgdragen voor informele goedkeuring en de beslissing door het lijnmanagement voorbereiden.


48

Bij beslissing omtrent wijzigingen op tactisch niveau, Cyclus 2 (einde system life cycle is nog niet bereikt), kunnen lager in de organisatie worden belegd. Deze taak kan worden belegd bij personen of gremia die op basis van hun rol beslissingen nemen, bijv de Adviesgroep Verkeerssystemen of het college van Verkeersmanagers. Wijzigingen op operationeel niveau kunnen door de adviseurs zelf worden genomen, mits het hoger gelegen niveau deze taken heeft gedelegeerd. Adviseurs (tactisch niveau) kunnen zijn: • Service Manager van de beheerorganisatie (MD); • Verkeerskundigen (Regionale Directies, AVV/IBW en AVV/IBA); • Systeemhouders en de Applicatiebeheerders (AVV/IBB); • Systeemspecialisten (AVV/IBI). Om de adviseurs is staat te stellen een goed onderbouwd advies uit te brengen zijn zij afhankelijk van management informatie. Deze informatie komt van specialisten die op hun beurt weer adviseur zijn op een specifiek deelgebied. Deze specialisten kunnen zijn: • Service Level Manager; • Kosten beheerder; • Capaciteitsbeheerder; • Helpdesk; • Systeembeheerders; • Operators. Opmerking Bovenstaand overzicht is gebaseerd op de lijnfuncties en functionele rollen zoals ze op dit moment binnen Verkeer en Waterstaat gehanteerd worden. Beter is in de toekomst uit te gaan van de logische rollen of organen zoals ze beschreven zijn in hoofdstuk 9 sub 5 van de managementsamenvatting Architectuur voor Verkeersbeheersing. 6.2.4

Waarop wordt er getoetst

Indien de betrokken deskundigen bij elkaar komen voor de systeemevaluatie en het bepalen van het wel of niet bereikt hebben van het einde van de system life cycle, is het noodzakelijk om vooraf de evaluatiecriteria af te spreken en vast te leggen. Evaluatiecriteria voor het bepalen van het einde van de system life cycle zouden kunnen zijn: • zijn de gebruikers tevreden met het systeem; • zijn er politieke, maatschappelijke en/of verkeerskundige ontwikkelingen die aanleiding geven tot herbezinning. M.a.w. komt met tot een andere probleemdefinitie op strategisch gebied; • zijn de onderhoudskosten ontoelaatbaar hoog; • voldoet het systeem aan de gedefinieerde architectuur; • zijn er voor één verkeerskundige toepassing meerdere ICT oplossingen (eiland automatisering); • is de gebruikersorganisatie anders georganiseerd dan ten tijde van de systeemontwikkeling en is hierdoor is de systeemfunctie achterhaald; • zijn aanleverende en/of afnemende systemen van data aan het eind van hun life cycle. M.a.w. past het systeem nog in de systeemketen; • worden kritieke componenten nog ondersteund c.q. zijn deze nog onderhoudbaar; • is de beschikbaarheid van het huidige systeem voldoende.


49

Om bovenstaande toetsingscriteria te kunnen gebruiken is informatie nodig om ze te voeden, zoals beleidsadviezen, taakuitvoeringconcepten, trends binnen de ICT etc. Uitkomsten uit de evaluatie kunnen zijn: 1. het huidige systeem voldoet en functionele (verkeerskundige) aanpassing is niet noodzakelijk; 2. het systeem voldoet aan de verkeerskundige doelstelling maar aanpassing is toch noodzakelijk (bijv. door te hoge exploitatiekosten of technische ontwikkelingen in de markt); 3. het huidige systeem wordt bevroren en er wordt een nieuw systeem ontwikkeld dat voldoet aan de nieuwe verkeerskundige doelstelling; 4. De ontwikkeling van het bestaande systeem wordt bevroren maar er wordt geen nieuw systeem ontwikkeld. 6.3 Ontwikkeling helpt beheer en andersom

In bovenstaande paragrafen is aandacht besteed aan het begrip “system life cycle” met als doel grip te houden op de kwaliteit van de dienstverlening en de daarbij gebruikte systemen en het moment te kunnen bepalen waarop nieuwe systeemontwikkeling gewenst is. In de meeste gevallen zal na een evaluatie blijken dat met een wijziging additionele functionaliteit geïmplementeerd kan worden of een technische aanpassing c.q. migratie volstaat. In het algemeen zullen wijzigingstrajecten dus talrijker zijn dan de bouw van nieuwe systemen. Het is voor de ontwikkelafdeling daarom moeilijk verbeterde ontwikkelmethoden in de praktijk te brengen en hiervan te leren. Bovendien brengt gebrek aan ervaring met deze nieuwe methoden nog al wat risico’s met zich mee voor de ontwikkeling van het nieuwe systeem, omdat parate kennis van de ontwikkelmethode nog niet optimaal is. Het kan daarom zinvol zijn de ontwikkelafdeling te betrekken bij grote wijzigingen, waarbij additionele functionaliteit geïmplementeerd moet worden. Op deze manier kunnen zij ontwikkelmethoden in de praktijk toetsen en kennis hiervan overdragen naar de beheerafdeling. Andersom neemt de ontwikkelafdeling kennis van de beheerproblematiek en kan zij bij de ontwikkeling van nieuwe systemen hiermee rekening houden. Bij deze samenwerking blijft de verantwoordelijkheid bij de beheerafdeling. Bij de ontwikkeling van nieuwe systemen is het altijd noodzakelijk de beheerafdeling te betrekken. Het voornaamste doel hierbij is het bewaken dat de systeemspecificaties “meetbaar”zijn en de beheerspecificaties integraal onderdeel uitmaken van de systeemspecificatie, zodat het systeem na oplevering zonder problemen door de beheerafdeling wordt geaccepteerd voor exploitatie. 6.4 Gebruikte documentatie

Titel Managementrapport Architectuur voor Verkeersbeheersing AVB Organisatie Architectuur P.OA.p1 “Beheren met de Kleine b” eindrapportage nov. 1999 Inrichting operationele beheerprocessen DVM


50

Auteur AVV AVV

Omschrijving Management Rapport van AVB, werkversie 0.4

De organisatie architectuur binnen het raamwerk van de architectuur voor verkeersbeheersing beschrijving van de DVM Verkeerskundige Van processen, het operationeel verkeersmanagement Meggelen Consultancy en de IT beheerprocessen AVV – MD- Inrichting operationele beheerprocessen DNB - DON dynamisch verkeersmanagement van de collectieve beheerorganisatie

Titel Eindrapport Betrouwbaar op weg IT service Management een introductie Beheer van informatie systemen (vijfde druk) CMM


51

Auteur RWS ITSMF Prof. dr. ir. M. Looijen Software Engineering Institute

Omschrijving Basis voor pro-actief landelijk verkeersmanagement Beschrijving van de ITIL beheerprocessen (handboek) Methoden en technieken voor het beheer van informatie systemen. Capability Maturity Model

State of the Art rapport KC Kwaliteitszorg voor Systeemontwikkeling

Recommend Documents