Het ontwikkelen van informatiesystemen op een iteratieve wijze vereist meer nog dan bij klassieke ontwikkelmethoden de inzet van geautomatiseerde hulpmiddelen. Beheersing van de stroom van commentaar, probleemmeldingen en (nieuwe) wensen zijn eigenlijk alleen goed mogelijk met behulp van een centrale repository waarop een set goed geïntegreerde tools opereert, aldus Kees A. Jansen, consultant bij Cap Gemini.
Iteratieve systeemontwikkeling (iad, iterative application development) kent drie fasen, die herhaald worden doorlopen: definitiestudie, pilot-ontwikkeling en invoering. Elke iteratie resulteert in een zogenoemde pilot, een volledig operationele subset van het beoogde informatiesysteem dat als zodanig kan worden ingevoerd in de organisatie. Het resultaat van het vroege gebruik in de praktijk is een vrijwel constante stroom van opmerkingen, wensen, probleemmeldingen en ander commentaar: de terugkoppeling. Deze vormt een belangrijke invoer voor volgende iteraties.
Een aantal andere kenmerkende eigenschappen van iad zijn:
– een nadrukkelijke en intensieve betrokkenheid van gebruikers en opdrachtgever bij het ontwikkelproces, ondermeer door middel van veelvuldige workshops;
– compacte, slagvaardige teams van ontwikkelaars (A-teams) en gebruikers (U-teams);
– speciale projectmanagementtechnieken als time-boxing, gericht op het halen van het maximale rendement bij gefixeerde grootheden op het gebied van tijd en budget.
Bij de ontwikkeling van tools bij Cap Gemini’s Skill Centre Tools wordt een aantal projecten parallel uitgevoerd. Elk project heeft een duidelijk gedefinieerd resultaat (een eerste versie van een nieuw product of een nieuwe versie van een bestaand product) en een vastgestelde einddatum.
Bij een typisch project met de duur van een kwartaal wordt gebruik gemaakt van één van de mogelijke iad-scenario’s: incrementele ontwikkeling. In dat scenario wordt de fase van de definitiestudie (circa drie weken) slechts éénmaal (aan het begin van het project) in zijn geheel doorlopen. Bij elke volgende iteratie worden slechts enkele activiteiten van die fase opnieuw uitgevoerd, met name het aanscherpen van de systeemeisen (op grond van de ontvangen terugkoppeling), het bijstellen van het pilot-plan (geeft aan welke pilots in totaal ontwikkeld zullen worden) en het opstellen van het pilot-ontwikkelplan voor de komende iteratie. Elke ontwikkel-iteratie duurt vervolgens één week. Na een aantal iteraties (in het voorbeeld zes) wordt ten slotte de fase Invoering (circa vier weken) eenmalig doorlopen. In deze fase zet men de puntjes op de i; er wordt een beta-versie opgeleverd en geen nieuwe functionaliteit meer ingebouwd; er worden alleen problemen opgelost, en uiteindelijk vindt oplevering plaats van software als gereed product.
Bij het Skill Centre Tools verstaat men onder Invoering het ter beschikking stellen van de pilot aan (potentiële) gebruikers. Het gaat hier immers om productontwikkeling. Binnen de fase Pilot-ontwikkeling komt overigens n�g een iteratie voor: de dagelijkse build. Aan het eind van elke dag wordt alle software opgeleverd en voor zover mogelijk ook gelabeld. Aan de hand daarvan wordt ’s nachts automatisch een nieuwe versie van het product gebouwd. Dit vereist dat de incrementen klein zijn: de ontwikkeltaken worden zodanig gepland dat ze maximaal twee dagen duren (inclusief specificatie en test).
Centrale repository
In tegenstelling tot lad (linear application development) kent iad geen ‘mijlpaalproducten’ aan het eind van een fase van de ontwikkelcyclus. In plaats daarvan wordt gebruik gemaakt van een centrale repository, waarin alle informatie omtrent het informatiesysteem in ontwikkeling (of in onderhoud) wordt opgeslagen. Vanzelfsprekend is het mogelijk om uit die repository documenten te genereren, maar die hebben altijd een tijdelijk karakter: het zijn slechts momentopnamen.
Welke informatie wordt nu in die centrale repository vastgelegd en welke geautomatiseerde hulpmiddelen staan ons daarbij ten dienst? Voor de hand liggend is dat specificatie en ontwerp van het informatiesysteem in de repository terecht komen. Tools die daarbij behulpzaam zijn, zijn de zogeheten case-tools. Het Skill Centre Tools maakt gebruik van het in huis ontwikkelde Systems Development Workbench (SDW), met name de modulen OO (Object Oriented Modelling), DM (Entity Relationship Diagramming), ST (State Transition Diagramming) en IP (Relationship Matrices).
Die centrale repository legt nog veel meer vast:
eisen (als resultaat van de eerste van fase van iad: ‘Requirements Definition Study’), projectstructuur, productportfolio, projectorganisatie, ontwerpbeslissingen, besprekingsverslagen, projectprocedures, standaarden en terugkoppeling afkomstig van testers en gebruikers van de diverse pilots.
Dit alles wordt eveneens met behulp van SDW gedaan, veelal in een door de gebruiker gedefinieerde structuur. Door zijn haar flexibiliteit leent SDW zich uitstekend voor dergelijke uitbreidingen van de repository-structuur bovenop de door de SDW-modulen gedefinieerde structuur [1,2].
Terugkoppeling
De laatstgenoemde categorie van informatie, de terugkoppeling, wordt met SDW vastgelegd, en wel met behulp van SDW-Itim, een set van modulen die de ‘service management procedures’ van Itil (Information Technology Infrastructure Library) ondersteunen. Deze theorie onderscheidt processen die noodzakelijk zijn voor de exploitatie van een IT-infrastructuur. Binnen SDW-Itim zijn modulen beschikbaar die een aantal van deze processen ondersteunen. Zonder verder in te gaan op de details van de diverse Itil-processen en de wijze waarop deze met behulp van SDW-Itim te ondersteunen zijn, schetsen we nu hoe de stroom van terugkoppeling te beheersen valt.
De terugkoppeling kan een externe oorsprong hebben (buiten de grenzen van het lan, waarbinnen de systeemontwikkeling plaats heeft) of een interne. In het externe geval bereikt de terugkoppeling via (e-)mail, telefoon of fax de helpdesk. De melding wordt geregistreerd in de Itim-helpdeskmodule, waarbij genoteerd wordt wie de melder is (daarbij kan men putten uit een bestaande database van gebruikers en organisaties) ten behoeve van een eventuele terugkoppeling. Als de eerstelijns helpdesk de melding niet direct kan afhandelen, wordt de melding een incident. Heeft de terugkoppeling een interne oorsprong, dan kan de melder direct een incident opvoeren.
Bij een incident behoort een bewaker en een behandelaar. Bij opvoering van het incident wordt als behandelaar de persoon die de rol van ‘problem manager’ vervult ingegeven. Met behulp van de ‘SDW-Notifier’ wordt de betrokkene (door middel van een pop-up scherm) verwittigd van het feit dat een (nieuw) incident aan zijn lijst is toegevoegd. De ‘problem manager’ zal het incident analyseren en een van de leiders van het A-team tot eigenaar ervan maken door hem als bewaker aan te wijzen. De ‘Notifier’ zorgt er ook nu voor dat de betrokkene van dat feit op de hoogte wordt gebracht.
De leider van het A-team beoordeelt het incident en stelt vast of het als probleem moet worden gekarakteriseerd of dat het een wens is. Problemen moeten worden geanalyseerd: de A-teamleider benoemt een van de teamleden tot behandelaar (die hiervan weer verwittigd wordt via de Notifier). Is de oorzaak gevonden, dan wordt het probleem een bekende fout. Meerdere problemen kunnen tot dezelfde bekende fout leiden.
In de planningsfase van een nieuwe iteratie worden bekende fouten en wensen beoordeeld, prioriteiten toegekend en, indien van toepassing, in de planning opgenomen. Ze worden dan gebundeld tot één of meer wijzigingsvoorstellen, die uiteindelijk leiden tot werkopdrachten. De wijzigingsvoorstellen worden gekoppeld aan het project waarvoor de planning wordt opgesteld. Daarnaast worden ook de systeemeisen gekoppeld aan het project. Op die wijze is gemakkelijk een overzicht te krijgen van welke systeemeisen, fouten en wensen zullen worden geadresseerd in de komende iteratie.
Korte procedure
Gedurende de looptijd van het project vindt een groot aantal iteraties plaats: wekelijkse, die resulteren in pilots op CD, en dagelijkse, die resulteren in builds op het netwerk. Beide leveren veel interne terugkoppeling op. In plaats van daarvoor de geschetste procedure te volgen, worden dergelijke incidenten veel directer behandeld. In de planning is rekening gehouden met een percentage aan reserveruimte voor het oplossen ervan. Het incident krijgt als initiële behandelaar de problem manager, die uitzoekt wie de bewaker is. De bewaker, de A-teamleider, wijst één van de teamleden aan als behandelaar. Zodra deze het incident heeft opgelost en getest, wordt de status van het incident op ‘Build’ gezet en de behandelaar gewijzigd in de leider van het testteam. Deze zal een van de leden van het testteam aanwijzen (als behandelaar noemen) om na te gaan of een en ander correct is uitgevoerd. Zo niet, dan wordt de status op ‘Not Resolved’ gezet, wordt bij het incident commentaar ingegeven en wordt als behandelaar weer de A-teamleider genoemd. Is het wel goed, dan wordt het incident doorgestuurd naar de problem manager, die zorgt voor terugmelding aan de indieners. Telkens wanneer de behandelaar of de bewaker wijzigt, wordt de betrokkene via de ‘Notifier’ op de hoogte gesteld van het feit dat een incident bij hem in behandeling of in bewaking is genomen. Op die wijze is een soort werkstroom ontstaan, waarbij alle betrokkenen het onderhanden werk direct op hun agenda vinden.
Gebruikers willen graag weten in welke versie van de software hun wensen gehonoreerd zullen zijn of – in het negatieve geval – willen vernemen dat deze, om welke reden dan ook, niet zullen worden gehonoreerd.
Dankzij een nauwkeurige registratie van de meldingen en de koppeling van melding aan incident, aan bekende fout of wens en ten slotte aan wijzigingsvoorstel, is te traceren wie verwittigd moet worden zodra de wijzigingen zijn geïmplementeerd. Omdat de wijzigingen ook gekoppeld zijn aan een project (dat resulteert in een of meer producten van een bepaalde versie), kan het proces van terugkoppeling gemakkelijk plaatsvinden. Het is zelfs mogelijk dat geautomatiseerd te doen via e-mail, mits het e-mail-adres van de indiener bekend is.
Impactanalyse
Aangezien bij het Skill Centre Tools met behulp van SDW ook de specificaties en het ontwerp van de software in dezelfde centrale repository worden vastgelegd als die waarin de terugkoppeling terecht komt, is het tevens mogelijk bij wijzigingsvoorstellen te analyseren welke impact de wijziging heeft op andere configuratie-items. Ook hier biedt SDW-Itim de helpende hand. Uitgaande van het primaire configuratie item (ci) kan de gebruiker navigeren langs configuratie-items die daaraan gerelateerd zijn (Met ci wordt in deze context bedoeld: een of meerdere componenten uit de repository, bijvoorbeeld een klasse, een entiteittype of een attribuut.) Wel moet per ci beoordeeld worden of de wijziging inderdaad effect heeft op het ci. Dat configuratie-item is dan ook te koppelen aan het wijzigingsvoorstel, opdat bij implementatie niet vergeten wordt ook daar een wijziging aan te brengen. Het nieuwe ci kan op zich opnieuw basis zijn voor verdere analyse op zoek naar nog andere ci’s die mogelijk aanpassing behoeven. Voorwaarde voor dit alles is dat bij specificatie en ontwerp ook werkelijk relaties gelegd worden met andere componenten. Veelal gebeurt dat impliciet doordat het gebruikte case-tool dergelijke relaties al zelf aanbrengt. In andere situaties moet er expliciet voor gezorgd worden dat componenten aan elkaar gerelateerd zijn. Zelfgemaakte consistentiecontroles kunnen behulpzaam zijn bij de naleving van daartoe geldende standaarden.
Zo vroeg mogelijk
Kenmerkend voor iteratieve systeemontwikkeling is de veelvuldige terbeschikkingstelling van pilots aan gebruikers en testers. De bedoeling daarvan is om in een zo vroeg mogelijk stadium zo veel mogelijk terugkoppeling te krijgen; die vormt een belangrijke invoer bij volgende iteraties. Beheersing van de stroom van commentaar, probleemmeldingen en (nieuwe) wensen zijn eigenlijk alleen goed mogelijk met behulp van een centrale repository waarop een set goed geïntegreerde tools opereert. Het kort-cyclische karakter van iteratieve systeemontwikkeling vereist bovendien een pragmatische aanpak, waarbij snelheid van reactie prevaleert boven bureaucratische procedures, zonder dat aan zorgvuldigheid (van vastlegging) voorbij wordt gegaan.
De heer K.A. Jansen is consultant Methoden, Technieken en Tools bij Cap Gemini.
Literatuur
[1] K.A. Jansen: SDW tussen tool en meta-tool. Informatie, jaargang 35, 1993, themanummer, pag. 750-756.
[2]. Jansen, K.A. en Jacobs, T.M.: Ontwerpen van informatiesystemen met SDW. Academic Service, 1996.
[3] Gilb, T.: Principles of Software Engineering Management. Addison-Wesley, 1988.
[4]. J. Martin: Rapid Application Development. MacMillan Publishing Company, 1991.
[5]. R.J.H. Tolido (met bijdragen van Th.J.G. Derksen en Th.H. Visschedijk): IAD – Het iteratief ontwikkelen van informatiesystemen. Academic Service, 1996.
