Managed hosting door True

Ontwerp vergt een permanente verbinding tussen specificatie en realisatie

Flexibel bestek

 

Systemen ter ondersteuning van de core-business in een organisatie zijn niet altijd voorzien van actuele specificaties. Met name als een systeem veel onderhoud vergt, zullen specificaties vaak aan verandering onderhevig zijn en niet altijd in de pas lopen met het gerealiseerde. Het in kaart brengen van de verschillen en het vinden van de oorzaak hiervan is al de helft van de oplossing. Om de verschillen weg te werken is het noodzakelijk een permanente verbinding tussen specificatie en realisatie te leggen, legt een zelfstandig gevestigd interim-manager uit.

Om het ontwikkelingsproces van informatiesystemen zo snel en soepel mogelijk te doen verlopen heeft de IT-professional in de loop van de tijd steeds meer de beschikking gekregen over methoden, technieken en hulpmiddelen. In de praktijk leidt het gebruik hiervan echter niet altijd tot een bevredigend resultaat. Veelal ligt de kern van de problematiek in het fenomeen dat de betrokken partijen anders tegen de zaak aankijken. Gebruikers denken in pakketten van eisen, ontwerpers en programmeurs in de structuren van de hulpmiddelen die zij gebruiken. Deze denkkaders willen nog wel eens uiteenlopen en de vertaling van het een in het ander verloopt niet altijd even soepel.

Toeters en bellen

Het startsignaal om een systeem te ontwikkelen is afkomstig van de gebruikersorganisatie. Die zet de specificaties of een wijziging op een bestaand systeem in grote lijnen op papier. Vervolgens gaan hiermee de ontwerpers aan de slag. Deze vertalen de specificatie in een detailontwerp met behulp van een ontwerphulpmiddel (een zogenaamde 'workbench'). Hierbij heeft de detailontwerper de vrijheid zoveel toeters en bellen van het hulpmiddel te gebruiken als hem goeddunkt. Wat het voor de volgende in de keten - de systeemontwerper - lastig kan maken de voor hem essentiële informatie uit het detailontwerp te halen. Het verkrijgen van een goed overzicht wordt alleen maar moeilijker, als het ontwerp al veel realisatiedetails bevat. De systeemontwerpers krijgen daardoor onvoldoende vrijheid om een technisch verantwoord systeem te bouwen. In de praktijk grijpen de systeemontwerpers terug naar de gebruikersspecificatie om te bezien welke technische vrijheden men zich nog kan veroorloven. Het detailontwerp wordt zodoende op een aantal vlakken niet gevolgd. Vervolgens ontwikkelt men een variant die ook aan de gebruikersspecificatie voldoet.
Het doorvoeren van wijzigingen in een systeem maakt de problemen alleen maar groter. Bij nieuwe releases gaan het ontwerp en het gerealiseerde steeds verder uit elkaar lopen, wat nog wordt versterkt door de dagelijkse praktijk. Bij spoedimplementaties van nieuwe functionaliteit wordt het ontwerptraject in eerste instantie soms overgeslagen. De systeemontwikkelaars kunnen - als er sprake is van een variant van iets bestaands - zonder een detailontwerp, snel iets realiseren. Het detailontwerp wordt dan in een later stadium bijgewerkt. Het risico bestaat dan dat een specificatie achteraf helemaal niet meer wordt gemaakt. In de praktijk komt het ook voor dat gespecificeerde functionaliteit of wijzigingen het realisatiestadium nooit bereiken. Het detailontwerp raakt dan vervuild met specificaties die nergens terug te vinden zijn. Het resultaat is dat de wijze van ontwerp niet meer aansluit op de wijze van systeemontwikkeling. Nog even de risico's in een dergelijk traject op een rij: overspecificatie; ontoegankelijke specificaties; dubbele of tegenstrijdige specificaties; niet realiseerbare specificaties; het overslaan van een specificatie; het bijwerken van specificaties na realisatie; vervuiling van het ontwerp met niet gerealiseerde specificaties en versieverschillen.

Stappenplan

Bij vrijwel alle soorten systemen komt het voor dat er op verschillende manieren naar gekeken wordt en vergeet niet dat er ook anders gedacht kan worden over de eisen die men aan het systeem stelt. Het openbaart zich met name bij legacy-systemen waar het vele onderhoud een kloof heeft geslagen tussen specificaties en het gerealiseerde. Echter ook bij moderne systemen is het niet vanzelfsprekend dat de gebruiker in dezelfde termen denkt als de ontwerper en ontwikkelaar.
De eerste stap om de kloof tussen specificatie en realisatie te dichten, bestaat uit het in kaart brengen van de begripsverschillen. Dit is mogelijk door de wijze van specificeren en de manier van realiseren met elkaar in conflict te brengen. Bij de confrontatie is het ook van belang te achterhalen wat de oorzaak is van het ontstaan van de verschillen tussen specificatie en realisatie. Daarmee komt de totale omvang van het probleem aan de oppervlakte. Met deze kennis start het zoeken naar een gemeenschappelijk begrippenkader waarmee de kloof voortaan is te overbruggen.
Specificatie en realisatie overlappen elkaar meestal, zodat het zeker van belang is overeenkomsten en verschillen bloot te leggen. Een aantal principes in specificatie en realisatie zijn direct met elkaar in verband te brengen. Bijvoorbeeld de specificatie van de gegevensopslag komt veelal voor een groot deel overeen met de realisatie en hetzelfde geldt voor het schermontwerp. Prototypen van schermen in de specificatie zijn vrijwel identiek in het gerealiseerde terug te vinden.
Grotere verschillen zijn te vinden bij de specificatie en realisatie van bijvoorbeeld de controles en de wijze van verwerking van transacties. De specificatie kan al een oplossingsrichting bevatten welke niet altijd in het gerealiseerde is gevolgd. Het gerealiseerde heeft wel min of meer dezelfde uitwerking, maar er is niet altijd een direct logisch verband te leggen tussen specificatie en realisatie.
Om de specificatie en de realisatie op één lijn te brengen is een gemeenschappelijk begrippenkader nodig. Een voor alle partijen bevredigend begrippenkader heeft als effect dat men elkaars taal spreekt en de onderlinge afhankelijkheden kent. Aan de hand van het gemeenschappelijke begrippenkader zijn ontwerpen en een beschrijving van de specificatie in één ontwerpbasis onder te brengen. Gebruikers, ontwerpers en programmeurs maken in dezelfde gemeenschappelijke ontwerpbasis gebruik van de specificaties van het gewenste en de beschrijvingen van het gerealiseerde.

De gemeenschappelijke ontwerpbasis

Met een gemeenschappelijk begrippenkader kan zowel de detailontwerper als een systeemontwerper of programmeur uit de voeten. Het begrippenkader is zodanig van opzet dat detailontwerpers enerzijds en technisch ontwerpers of programmeurs anderzijds hun eigen visie op de specificatie en de realisatie hebben en houden. Voor aspecten van het ontwerp, zoals gegevensopslag en schermlay-out die voor beide gezichtspunten relevant zijn, vindt een integratie plaats. Daarnaast blijft het mogelijk dat detailontwerpers en systeemontwerpers of programmeurs begrippen hanteren die alleen voor specificatie of uitsluitend voor realisatie van belang zijn. Waar mogelijk worden deze wel met de overige begrippen in verband gebracht.
Een gemeenschappelijk begrippenkader vormt een goede basis voor de toekomst. Alvorens een nieuwe start te maken, moet de historisch gegroeide kloof eerst nog worden overbrugd. Hiervoor is een integratieslag nodig van bestaande ontwerpen en het gerealiseerde. De opbouw van de gemeenschappelijke basis kan plaatsvinden aan de hand van geconstateerde overeenkomsten. Daarnaast moeten de geconstateerde verschillen worden weggewerkt en de ontbrekende of onvolledige specificaties worden aangevuld.
Het opbouwen van een gemeenschappelijk detail- en systeemontwerp vergt een integratie van de bestaande ontwerpen. Dit behelst onder meer het verwijderen van delen van de specificatie die niet nodig zijn voor de realisatie, of het verwijderen van specificaties die nooit gerealiseerd zijn. Daarnaast is het nodig het detailontwerp aan te vullen met gerealiseerde functionaliteit die nooit in dit ontwerp is beschreven. Dergelijke integraties vergen veel inspanningen. Bij de uitvoering van deze werkzaamheden is geautomatiseerde ondersteuning mogelijk. Met re-engineering technieken wordt het gerealiseerde geanalyseerd en wordt een kader voor het detailontwerp gemaakt. Anderzijds kan middels geautomatiseerde hulpmiddelen een analyse plaatsvinden op verbanden tussen het detailontwerp, het systeemontwerp en het gerealiseerde. Na een globale analyse van de verschillen is het uitzoeken van details makkelijk te automatiseren. Door de ontwikkeling van hulpmiddelen kan de feitelijke integratieslag voor vrijwel 100 procent geautomatiseerd plaatsvinden.
Op het moment dat het detailontwerp, het systeemontwerp en de realisatie op één lijn zijn gebracht, ontstaat een krachtige gemeenschappelijke ontwerp- en documentatie-basis. Het ontwerp bevat alle voor zowel gebruikers, ontwerpers als programmeurs relevante informatie, eenduidig gegroepeerd en met elkaar in verband gebracht. Dit levert voor elk der partijen toegevoegde waarde op, doordat niet alleen de eigen begrippen terug te vinden zijn, maar ook de aansluiting met het begrippenkader van collega's. Om te zorgen dat alle partijen hun werk kunnen blijven doen, is het van belang dat het nieuwe allesomvattende ontwerp voor iedereen toegankelijk is.
Zo kan er bijvoorbeeld gekozen worden voor een op internettechnologie gebaseerde ontsluiting. Dit maakt de specificatie en de wijze van realisatie voor iedereen toegankelijk en biedt bovendien uitgebreide mogelijkheden verbanden te leggen en in specificaties te zoeken. Als ingang kan voor de gebruiker de menustructuur dienen, zoals de gebruiker die kent van het systeem. Daarnaast kunnen ontwerpers en programmeurs via de functies van het systeem zoeken naar de gewenste specificaties. Diverse herkenningspunten zoals schermen, gegevens, menu's, rapporten of berichten zijn in het ontwerp terug te vinden en via hyperlinks met elkaar in verband gebracht.

Invoering

Ontwerpers en ontwikkelaars maken gebruik van eigen ontwerp- en ontwikkel-gereedschappen. Deze gereedschappen hanteren een eigen vorm om ontwerpen en broncode vast te leggen. Deze vorm zal niet altijd technisch op elkaar aansluiten en in een gemeenschappelijke vorm te gieten zijn. Derhalve zijn interfaces nodig die de hulpmiddelen op de gemeenschappelijke ontwerpbasis aansluiten. De bestaande hulpmiddelen krijgen een interface zodat zij toegang krijgen tot de benodigde ontwerponderdelen uit het gemeenschappelijke ontwerp. Aanpassingen gedaan met de ontwerp- en ontwikkel-hulpmiddelen dienen in de gemeenschappelijke ontwerpbasis terecht te komen en wel in de betreffende ontwerponderdelen. Om deze aansluiting tot stand te brengen zijn dezelfde hulpmiddelen toe te passen als die voor het oorspronkelijke vullen van de gemeenschappelijke ontwerpbasis zijn gebruikt. Deze hulpmiddelen zijn immers gekozen om de oorspronkelijke met de ontwerp- en realisatie-hulpmiddelen ontwikkelde onderdelen in een gemeenschappelijke ontwerpbasis onder te brengen. Alleen werken ze nu niet op het hele ontwerp of de hele realisatie, maar slechts op een bepaald onderdeel.
Versies van specificaties en het gerealiseerde willen nog wel eens door elkaar lopen. Een gemeenschappelijke ontwerpbasis bevat zowel specificatieaspecten als realisatiedetails. Een integratie van deze aspecten vereist dat het ontwerp en de realisatie van dezelfde versie van een systeem ook als een samenhangende versie zijn geadministreerd. De totale ontwerpbasis dient dus onder adequaat versiebeheer te staan. Indien er voor de broncode al een configuratie-managementsysteem in gebruik is, kan dit tevens voor het beheer van de ontwerpen dienen. Hierdoor vallen ontwerpers en ontwikkelaars onder hetzelfde versieregime en kunnen wijzigingen goed worden overzien en beheerd.
Nadat een nieuwe gemeenschappelijke ontwerpbasis is ontwikkeld, dient deze nog in het reguliere ontwikkelproces te worden ingevoerd. Dit is relatief eenvoudig te realiseren, indien de hulpmiddelen zijn aangesloten op de gemeenschappelijke ontwerpbasis. De invoering kan dan gefaseerd plaatsvinden. Zodra deze basis beschikbaar is, kan zij als naslagwerk dienen voor alle betrokkenen. Vervolgens kunnen eerst de detailontwerpers aansluiten op de ontwerpbasis en daarna de systeemontwerpers en ontwikkelaars. Tot volledige invoering is de ontwerpbasis actueel te houden met geautomatiseerde (re-engineering) hulpmiddelen.

Algehele stroomlijning

Het op één lijn brengen van specificatie en realisatie is de grootst denkbare winst. Hinderlijke verschillen en begripsverwarring tussen specificatie en realisatie zijn dan niet meer aanwezig. Door wederzijds begrip neemt ook de uitwisselbaarheid van rollen in het traject toe. Een detailontwerper kan een deel van de taak van de systeemontwerper overnemen en andersom. Voor korte en eenvoudige realisatietrajecten is het zelfs mogelijk deze rollen geheel te integreren. Hierbij maakt een systeemontwerper ook het detailontwerp. Dit is zodanig gestandaardiseerd dat de inhoud voor de opdrachtgever begrijpelijk en toetsbaar is. Door een wederzijdse toetsing en het ontbreken van een begrippenkloof neemt ook de kwaliteit van het product toe. De kans op niet eenduidige specificaties en foutieve interpretatie van specificaties wordt daarmee ook kleiner.
Het begrippenapparaat is specifiek voor het soort systeem dat wordt gebouwd. Dit vergt een opleiding van ontwerpers en programmeurs in de gehanteerde ontwerp- en realisatiesystematiek. Hierdoor kan een ontwerper en programmeur niet meer zijn eigen favoriete ontwerpmethode hanteren. Door het zich eigen maken van het begrippenkader is de opzet en structuur van het systeem voor de betrokkenen echter ook meteen duidelijk. Kort gezegd is het effect een algehele stroomlijning van het ontwerp- en realisatietraject. Hierdoor zijn ook algemene zaken als versiebeheer en inrichting van de serviceorganisatie efficiënter uit te voeren.
Tot slot nog even de consequenties van de gemeenschappelijke ontwerpbasis samengevat. Zorg voor een eenduidig begrippenkader en maak de rollen uitwisselbaar. Met de geschetste aanpak is de kwaliteit van het systeem zeker gediend. En neem de juiste maatregelen opdat het begrippenapparaat op het soort systeem is toegesneden. Voorts zijn een stroomlijning van ontwerp en realisatie en een adequate efficiëntie van de serviceorganisatie onontbeerlijk om een solide brug te slaan tussen specificatie en realisatie van elk systeem dat de core-business van een organisatie draaiende houdt.
 
Edmond van Houten, interimmanager

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/1390140). © Jaarbeurs IT Media.

?


Lees meer over


 
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×