Het ontwikkelen van informatiesystemen is geen routinewerk. In de jaren tachtig ontstond het begrip ‘software-crisis’, maar nog steeds worden projecten te laat opgeleverd, budgetten overschreden en laat de kwaliteit te wensen over. Ipse (‘Integrated Project Support Environment’), een raamwerk voor het beheer van een ontwikkelomgeving, kan een oplossing zijn volgens Ary Velstra, directeur van een softwarebedrijf.
Vrijwel vanaf de oprichting in 1987 is Ary Velstra lid van de Ipse Interest Group, een commissie van het NGI. Doel van deze werkgroep is het vergaren en uitdragen van kennis omtrent omgevingen voor het ontwikkelen en beheren van informatiesystemen. "Met vijftien actieve leden proberen wij steeds een nieuw aspect van Ipse aan te pakken en te presenteren. Afgelopen februari betrof dat een enquête over metrieken, gereedschappen voor het gebruik daarvan en een presentatie over de manier waarop een bedrijf ze kan gebruiken. Metrieken vormen echter slechts een onderdeel van een Ipse", aldus de directeur van Template Software Benelux.
"Zoals de naam aanduidt, is Ipse het concept van een geïntegreerde ondersteunende omgeving voor het ontwikkelen van informatiesystemen. Een complete omgeving, waarvan echter slechts algemene ideeën worden aangegeven, omdat zij moet worden aangepast aan de specifieke situatie van een bedrijf. Het nieuwe Ipse-model, dat wij in 1993 ontwikkeld hebben, is in grote lijnen op te splitsen in drie zuilen (figuur 1): ondersteuning van de technische ontwikkeling (links), van het projectmanagement (rechts) en van het versiebeheer (midden).
Deze zuilen zijn gebaseerd op het netwerk en het bedrijfsmodel van de onderneming. Hoewel tweedimensionaal getekend, omvat het model veel meer dimensies. Omdat projecten zelfs binnen eenzelfde organisatie vaak anders worden uitgevoerd, zou men bijvoorbeeld de verschillende soorten projecten als derde dimensie kunnen plaatsen."
"Aan de linkerkant – de ontwikkeling – staan vier kolommen. De belangrijkste aspecten van een project zijn het functionele model dat moeten worden gerealiseerd, de gegevensmodellen die daarbij worden gebruikt, het organisatiemodel en de middelen (mensen, technologie, gereedschappen, geld enzovoort) die nodig zijn voor de ontwikkeling. De verticale onderverdeling betreft de stappen waarin het project wordt uitgevoerd, bijvoorbeeld planning, analyse, ontwerp, programmeren, testen, en het daarbij gebruikte gereedschap," aldus Velstra.
Deze linkerzuil moet worden ingevuld met het juiste gereedschap (case-tools) en men moet beslissen welke kenmerken zullen worden gebruikt om de prestaties vast te leggen. Welke gereedschappen het best kunnen worden gebruikt, is sterk afhankelijk van de volwassenheid (maturity) van de ontwikkelorganisatie.
Aan de rechterkant staat projectmanagement met drie onderdelen. Velstra: "Dit betreft de beheersmatige kant van het ontwikkelen van informatiesystemen, waarmee de projectmanager en het hoofd van de ontwikkelingsafdeling te maken hebben. Allereerst het kwaliteitssysteem: hoe kun je garanderen dat je constante kwaliteit aflevert? Dat ligt in de lijn van ISO-9000, door de procedures te bepalen en vast te leggen. Resource management is vooral een kwestie voor het afdelingshoofd: hoe zijn de beschikbare middelen van de organisatie optimaal in te zetten, nu en in de toekomst. Het projectplan omvat een uitgewerkt plan voor de onderdelen en volgorde van het project, compleet met een inroostering van de benodigde menskracht. Wellicht nog het allerbelangrijkste en misschien het moeilijkste onderdeel is de communicatie: ervoor zorgen dat iedereen op elk moment weet wat hij of zij moet weten."
De rechts getekende verticale ingangen omvatten de organisatie van deze communicatie, de manier van projectplanning en de methode voor kwaliteitsborging.
Hoe verhoudt dit Ipse-model zich tot software engineering?
Velstra: "Ipse is een complete architectuur voor een ontwikkelomgeving waarmee men software engineering kan bedrijven; dat kan echter op veel manieren. Het SEI (Software Engineering Institute) in de Verenigde Staten heeft vijf niveaus van volwassenheid ten aanzien van software-engineering aangegeven. Daar horen ook verschillende ontwikkelingsvormen van de gebruikte Ipse bij; dat moet op elkaar aansluiten. Het software engineering model (SEM) is als basis gebruikt voor het Ipse-model."
Metrieken
Projecten beginnen met de definitie van het proces voor het ontwikkelen van een informatiesysteem. Allereerst beschrijft men alle stappen en activiteiten met bijbehorende hulpmiddelen en bepaalt men mijlpalen. Aan de hand van eerdere ervaringen wordt vervolgens een schatting gemaakt van de benodigde tijd en kosten. Ten behoeve van volgende projecten wordt de basis voor de schatting achteraf bijgesteld aan de hand van de bereikte resultaten. Zo leert men al doende. Dit is belangrijk voor programmatuurontwikkeling, omdat deze berucht is vanwege overschrijdingen van budget en levertijd. Uit een Nederlands onderzoek is gebleken dat vier van de vijf projecten aan dit euvel lijden. Onder druk van de geplande einddatum worden ontwikkelaars vaak gedwongen mindere kwaliteit te leveren.
Voor een goede projectbeheersing (project opgeleverd met de juiste kwaliteit volgens plan) zijn goede schattingen essentieel; hiervoor gebruikt men metrieken. Het rapport ‘Metrieken en software-ontwikkeling’ van de Ipse-IG definieert een metriek als een objectief meetbare grootheid voor het meten van tussenresultaten of het eindprodukt. Een bekend voorbeeld is het aantal programmaregels (loc: lines of code), een resultaat dat kan worden gemeten na afloop. Een metriek is ook te gebruiken voor het voorspellen van een resultaat, bijvoorbeeld het aantal entiteiten in het datamodel van een functioneel ontwerp of het aantal modules dat gedefinieerd is tijdens het technisch ontwerp. Met behulp van een voorspellende metriek zijn in bepaalde situaties vuistregels af te leiden, zoals: de totale projectkosten bedragen het zevenvoudige van de kosten van het functioneel ontwerp (in de eigen organisatie voor dit type projecten met deze hulpmiddelen enzovoort). Men maakt veel gebruik van functiepunten: een voorspellende metriek, afgeleid van het gemaakte functionele model. Het effect van afwijkingen in een situatie, bijvoorbeeld vanwege het gebruik van nieuw case-gereedschap, moet apart worden verdisconteerd.
Een voorwaarde voor het invoeren van metrieken is standaardisatie van het proces en zijn onderdelen; anders vergelijkt men appels met peren. Dit maakt het mogelijk om onderdelen tussen projecten te vergelijken en te voorspellen. Het gebruik van metrieken loopt dus parallel aan het definiëren en vastleggen van het ontwikkelingsproces. Samen leiden ze tot betere projectbeheersing. Het Ipse-IG rapport over metrieken bevat echter geen gedetailleerde beschrijving van metrieken zelf, alleen van hun gebruik.
Zijn er geen universele metrieken? Moet iedereen die zelf ontwikkelen voor zijn eigen omgeving?
Velstra: "Ja, behalve loc’s en functiepunten zijn er weinig universeel geldige maten. De keuze wordt geheel bepaald door wat een organisatie of projectmanager wil bereiken, door de strategie. Bij de gekozen strategie moeten de passende metrieken worden gevonden uit de eerder vastgelegde ervaringen. Dat ligt dus voor iedereen verschillend. Als algemene richtlijn propageren wij graag de goal-question-metric-strategie: welk doel wil men bereiken? Welke punten zijn daarbij van belang? En hoe meet men het succes van het resultaat? Dat levert de beste metrieken."
Velstra is sterk geïnteresseerd in het vinden van metrieken en het leren uit eerdere ervaring. Tijdens de Ipse-IG bijeenkomst in februari j.l. presenteerde hij het furps+model (functionality, usability, reliability, performance, supportability plus) dat bij HP is ontwikkeld door Grady c.s. en dat in twee boeken is vastgelegd. Grady geeft drie mogelijke ontwikkelstrategieën als voorbeeld: maximale klanttevredenheid, minimale ontwikkelinspanning en minimaal aantal fouten. Voor elk van deze strategieën bepaalt men vervolgens de belangrijkste aspecten en stelt men vast hoe die kunnen worden gemeten. Zo zijn de belangrijkste aspecten voor klanttevredenheid: de juiste functionaliteit, bruikbaarheid, betrouwbaarheid, snelheid en onderhoudbaarheid. Vervolgens moet men bepalen hoe deze aspecten gemeten kunnen worden en welke metrieken daarvoor geschikt zijn.
‘Quick Scan’
De Ipse Interest Group gaf in 1994 een rapport uit onder de naam ‘Quick Scan’, waarin door middel van een korte vragenlijst is vast te stellen in welk ontwikkelingsstadium een organisatie zich bevindt. Velstra: "De conclusie kan zijn dat men reeds een eind op weg is of dat de invoering van een Ipse voorlopig nog niet aan de orde is. Indien een Ipse-omgeving nuttig zou kunnen zijn, wordt verder met behulp van scenario’s aangegeven hoe en in welk tijdsbestek men een bepaalde fase kan afleggen; dat is mede afhankelijk van de grootte van de voorgenomen investeringen.
De vragenlijst bevat een twintigtal zogenoemde ‘pijnpunten’ zoals: ‘project duurt te lang’, ‘ontevreden klant/gebruikers’ of ‘slechte systeemdocumentatie’. Elk pijnpunt heeft een weegfactor (1-4) en kan invloed hebben op de volgende vier belangrijke beheersingsfactoren: kosten, middelen, kwaliteit en/of planning, waaraan ook een weegfactor van respectievelijk 4, 3, 2, 1 of 0 is toegewezen. De scores worden verzameld in een grote tabel en opgeteld. Het totaal bepaalt in welke van drie klassen de organisatie zich bevindt: ‘goed op weg naar een Ipse-omgeving’, ‘een Ipse-omgeving kan erg nuttig zijn’, of ‘de organisatie moet worden verbeterd voordat een Ipse zinvol is’.
Hoeveel bedrijven in Nederland werken met het Ipse-model?
Velstra: "Ik ken geen bedrijf dat het volledige Ipse-model heeft ingevoerd. Binnen een aantal grote bedrijven zijn wel enkele projecten die heel ver zijn gevorderd met een vrijwel volledige invulling. Ipse is een zaak van lange adem. Je moet ervaring opbouwen en dat is een kwestie van jaren. In Nederland wordt wel behoorlijk veel gemeten, vooral aan de linkerkant van het Ipse-model. Veel bedrijven hebben al wel een i-case-omgeving waarin case-gereedschap volledig geïntegreerd is en vierde-generatie talen worden gebruikt. Maar versiebeheer is een ondergeschoven kindje dat nog erg weinig aandacht krijgt. De beheersaspecten beginnen steeds meer aandacht te krijgen.
Minder dan 10 procent van de bedrijven is ISO-9000 gecertificeerd voor kwaliteitsborging. Veel bedrijven zijn er wel mee bezig, maar dat is zeker nog geen gemeengoed. Resource management staat nog in de kinderschoenen. Projectplanning is daarentegen wel redelijk algemeen ingevoerd."
Invoeren van Ipse
Het is geen eenvoudige zaak een Ipse-omgeving in te voeren en bovendien vraagt dat blijkbaar de nodige tijd. Organisatiedeskundige Nolan denkt ook in termen van jaren voor het bereiken van een volgende fase. Kennelijk is het niet mogelijk om stappen over te slaan. Wat zijn de problemen die moeten worden overwonnen?
Velstra: "Elke organisatie gebruikt nu eenmaal bepaalde manieren om problemen op te lossen. Die verander je niet zomaar. De organisatie is net gewend aan de bestaande situatie en als je daarvan onderdelen verandert, gaat het snel scheef. Mede daarom is het zo verschrikkelijk moeilijk om van bovenaf radicale veranderingen op te leggen. Mensen moeten de tijd hebben om zich aan te passen, de veranderingen te accepteren en hun weg opnieuw te vinden. Alle betrokkenen moeten het nut inzien van veranderingen en goed begrijpen waarom die zinvol zijn, en dat kost tijd." Het fundamentele probleem hierbij is volgens hem dat de invoering van een Ipse-omgeving vooral zinvol is voor topmanagement. De projectmanagers en medewerkers moeten extra werk doen zonder dat ze daarvoor direct beloond worden en moeten dus goed gemotiveerd zijn.
Hoeveel extra werk betekent een Ipse-omgeving voor de medewerkers? En bestaat ook niet het gevaar dat medewerkers hun eigen
tekortkomingen niet zullen willen rapporteren en die trachten te verdoezelen?
"Dat laatste is zeker niet ondenkbaar, vandaar dat een vertrouwensrelatie cruciaal is en dat de vastlegging van werkresultaten onder geen beding mag worden gebruikt voor individuele beoordelingen. Ipse staat of valt met een volwassen houding van zowel medewerkers als managers. Het extra werk valt erg mee. Een aantal zaken wordt ook nu al bijgehouden door de projectmanager. De extra tijd die een Ipse-omgeving vraagt zal voor de medewerkers liggen tussen 1-10 minuten per week en voor de projectmanager tussen de 5-15 minuten per week," stelt Velstra.
Behalve het invullen van werkbriefjes, zal iemand het informatiesysteem daarvoor moeten opzetten en bijhouden. Wordt dat gedaan door een staffunctionaris of door de projectmanagers zelf? Velstra: "Als het systeem van bovenaf wordt opgelegd, is dat uiteraard een centrale persoon. Maar de ideeën kunnen ook van onderaf komen: een projectmanager die het belang van Ipse inziet en het zelf organiseert. Als zo’n manager succes heeft, gaan anderen ook meedoen en groeit het gebruik in de organisatie."
Praktijk
In hoeverre heeft de invoering van een Ipse-omgeving zich in de praktijk bewezen? Zijn de gegevens van eerdere projecten inderdaad te gebruiken om kosten en tijd van projecten te voorspellen?
Velstra: "Zeker! In mijn bedrijf – dat internationaal werkt – hebben we een project estimator ontwikkeld voor de 4GL-omgeving. Omdat men in dit soort omgevingen niet even wat programma’s kan installeren, werken wij nauw samen met onze klanten. Wij beschikken inmiddels over veel ervaringen, verzameld over de hele wereld, waarmee nieuwe projecten nauwkeurig geschat kunnen worden. Het is wel even zoeken in de database en puzzelen om vergelijkbare projecten te vinden, maar dat schatten werkt prima. Je metrieken moeten wel steeds verder worden verfijnd en aangepast; daarmee moet je bezig blijven. Het opzetten van een Ipse-omgeving is een kwestie van lange adem en vergt blijvende inspanning, maar als je het goed doet, is het dubbel en dwars de moeite waard."
In hoeverre wordt Ipse internationaal gebruikt?
"Het idee van software engineering stamt uit de Verenigde Staten en de ideeën worden overal toepast. Het concept van Ipse is internationaal niet onbekend, maar Amerikanen zijn meer vertrouwd met Apse: een Ipse voor administratieve data-acquisitie. De uitwerking van het Ipse-model vond vooral in Nederland plaats, en daarin lopen we nogal voor op de rest van de wereld. Nederlanders houden er niet van om zomaar wat regeltjes te volgen: er moet een methode achter zitten. Wij zijn een methodisch volkje!"
Hein van Steenis, freelance-medewerker Computable
Literatuur
R.B. Grady Software Metrics: Establishing a company-wide program, Prentice-Hall (1987)
R.B. Grady Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall (1992)
W.S. Humphrey Managing the Software Process, Addison-Wesley (1989)
Ipse-IG Het nieuwe Ipse-model, NGI-rapport (1993)
Ipse-IG Enquête Metrieken, NGI-rapport (1994)
Ipse-IG De Quick Scan, NGI-rapport (1994)
Ipse-IG Metrieken en Software ontwikkeling, NGI-rapport (1995)
Software Engineering Institute Capability Maturity Model for Software, Version 1.1 (CMU/SEI-93-TR-24)
