Software als Kennisbron Jan Boef, Arie van Deursen, Paul Klint 1. Verborgen kennis in software-systemen. Bij veel bedrijven ligt de feitelijke kennis over bedrijfsprocessen vooral vast in programmatuur. Programma's voeren de betreffende processen - over het algemeen correct - uit, en zolang ze niet gewijzigd hoeven te worden heeft niemand behoefte om te weten hoe de programmatuur precies tot zijn resultaten komt. Veel programmatuur werkt jarenlang naar tevredenheid van de gebruikers zonder dat er wijzigingen in aangebracht hoeven te worden. Zo zijn er binnen grote organisaties vaak duizenden programma's die al langer dan 10 jaar niet zijn aangepast. Er zijn zelfs programma's uit het begin van de zeventiger jaren die sindsdien nooit gewijzigd of zelfs opnieuw gecompileerd zijn. Naarmate de programmatuur langer ongewijzigd in gebruik is, neemt het aantal mensen met kennis over de in deze programmatuur besloten bedrijfsprocessen af: ingehuurde medewerkers vertrekken weer en interne medewerkers krijgen na verloop van tijd andere functies binnen het bedrijf. Dit kan tot aanzienlijke kosten en vertragingen leiden wanneer op een gegeven moment de bedrijfsprocessen en de bijbehorende programmatuur aangepast worden. Om deze problemen het hoofd te bieden is het van belang de kennis besloten in programmatuur en in programma-modificaties expliciet toegankelijk te maken. Dit vereist het gebruik van geformaliseerde processen voor documentatie en onderhoud van programmatuur en een gedegen opzet van de software-logistiek. Binnen de ICT industrie staat deze formalisering nog in de kinderschoenen, zoals duidelijk blijkt uit de inspanning die nodig is geweest om de jaar-2000 problematiek op te lossen. Een dergelijke ongeformaliseerde werkwijze is, bijvoorbeeld, in de vliegtuigindustrie ondenkbaar. 2. De logistiek van software componenten. De uitdaging waar de software-logistiek voor staat is het combineren van continue levering met continue verandering. Dit zijn twee aspecten van de ICT functie van een bedrijf, die beide van belang zijn voor het bestaan het bedrijf, maar die elkaar eigenlijk niet goed verdragen. Voor het bedrijf van vandaag is het nodig dat geautomatiseerde produkten en diensten tijdig en ongestoord worden geleverd. Voor het bedrijf van morgen is het essentieel om middels nieuwe produkten en diensten in te spelen op de behoeften van de klant. Hierdoor ontstaat een spanningsveld tussen de noodzaak tot verandering enerzijds en het risico van verstoring van de continuïteit anderzijds. Om een brug te slaan tussen de ontwikkeling en de exploitatie van ICT produkten en diensten, is het noodzakelijk om de software-logistiek zorgvuldig op te zetten. Software-logistiek omvat de overdracht van programmatuur, documentatie, test cases, enz., van ontwikkeling via een of meerdere testfasen naar productie. In elk statusgebied moeten de juiste versies van de verschillende software-componenten beschikbaar zijn, moet de koppeling tussen bijvoorbeeld broncode en load module eenduidig vastgesteld zijn, en moet de correcte versie van de documentatie aanwezig zijn. Bovenal moet de wijze waarop nieuwe diensten en produkten worden ontwikkeld, zoveel mogelijk onafhankelijk zijn van de manier waarop zij worden geëxploiteerd. Voor de invulling van software-logistiek kunnen we leren van andere industrieën, die al vele jaren goedwerkende logistieke systemen gebruiken. Een systematische aanpak van software-logistiek omvat de volgende elementen (zie ook Figuur 1): - Een centraal magazijn van alle software componenten, zowel in bron- als load-formaat. - Uitgifte naar het ontwikkelproces vanuit het centrale magazijn. - Gestandaardiseerde inname van alle componenten uit het ontwikkelproces, inclusief Quality Assurance (QA). - Compilatieprocessen onafhankelijk van de individuele ontwikkelaar en het toegepaste ontwikkelgereedschap - Distributie van de benodigde componenten naar de doelomgeving - Activering van de componenten in de doelomgeving - Vastlegging van informatie over componenten De voordelen hiervan zijn overzichtelijkheid, zekerheid en snelheid. Overzichtelijkheid wordt verkregen doordat velerlei vragen snel te beantwoorden zijn, zoals: - Welke componenten zitten er in een systeem? - Welke componenten zijn in ontwikkeling of worden getest? - Welke versies bestaan er en wat is hun status? - Welke versie van welke component wordt waar gebruikt? - Wie heeft wat gedaan met een component? Zekerheid wordt verkregen doordat - De QA-processen gestandaardiseerd zijn. - De bewerkingen van componenten volledig gecontroleerd worden. - Handmatig ingrijpen sterk gereduceerd wordt - Altijd de juiste componentversies worden gebruikt - Bij het verwijderen van componenten alle gerelateerde componenten worden meegenomen - Release-matig gewerkt wordt, waarbij complete, integere subsets worden verwerkt in plaats van losse componenten. De snelheid wordt vergroot doordat: - De informatie over alle componenten altijd actueel is. - Componenten realtime opgehaald, bewerkt en geactiveerd kunnen worden. - De noodzaak tot testen afneemt. De totale tijd nodig voor het doorlopen van de stappen van het ontwikkelproces (inclusief compilaties en uitgifte en distributie naar productie) wordt aanzienlijk verkort (van velen uren tot minder dan een uur) door de ondersteuning die een geautomatiseerd systeem voor software-logistiek biedt. 3. Het borgen van kennis uit software-systemen. Binnen de software-logistiek dienen er momenten te zijn waarop kennis over software componenten wordt vastgelegd. In elke ontwikkelaanpak voor programmatuur zitten momenten waarop ``deliverables'' een status krijgen. Dit zijn de momenten om deze deliverables logistiek te administreren. Bovendien kunnen op dergelijke momenten de deliverables geanalyseerd worden, om zo de daarin opgeslagen kennis eenvoudig toegankelijk te maken voor toekomstig gebruik. Dit kan op verschillende manieren. Architectuurinformatie wordt vaak vastgelegd in schema's en plaatjes. Ontwerpinformatie kan worden vastgelegd in ontwerpgereedschap. Andere informatie kan als tekst worden vastgelegd. Al deze vormen van informatie kunnen als systeemdocumentatie van belang zijn tijdens de verdere levenscyclus van een applicatie. In de klassieke visie op systeemontwikkeling wordt documentatie opgeleverd bij oplevering van een softwaresysteem. Bij systeemwijzigingen worden alleen de wijzigingen gedocumenteerd. Dit heeft tot gevolg dat er al vrij snel geen integrale, actuele, documentatie van het systeem meer is. Een nog weinig gebruikte werkwijze is het automatisch genereren van systeemdocumentatie. Hierbij worden zowel individuele programma's als complete programmaportfolios geanalyseerd. Op basis van deze analyse wordt zowel tekstuele als grafische documentatie gegenereerd die via het Intranet toegankelijk gesteld kunnen worden. Zowel bij het oplossen van fouten als bij regulier onderhoud krijgt de onderhoudsprogrammeur sneller inzicht in structuur en werking van programma's. De werking van een documentatiegenerator wordt getoond in Figuur 2. Ook hier zorgt software-logistiek ervoor dat de gegenereerde documentatie een weerslag is van de draaiende systemen die in productie zijn of getest worden. Aangezien software-logistiek zowel de ontwikkeling als het beheer en de exploitatie van software omvat, wordt op deze wijze kennis vergaard die van belang is voor elke stap in de levenscyclus van een softwaresysteem. 4. Automatische documentatiegeneratie De inzet van geautomatiseerde, door de logistiek aangestuurde documentatiegeneratie kent een aantal voordelen: De afgeleide informatie is correct, actueel, en uniform over verschillende systemen heen. Documentatiegeneratie levert verder een besparing op omdat er geen mankracht meer gestoken hoeft te worden in het schrijven en bijhouden van documentatie. Dit kan oplopen tot een initiele besparing van een aantal mensjaar. Daarnaast blijkt uit onderzoek (J. Corbi, Program Understanding: Challenge for the 1990s, IBM Systems Journal, 28(2):294-306, 1989) dat de onderhoudsprogrammeur 50% van zijn tijd besteedt aan het proberen te begrijpen van een systeem. Door het gebruik van on-line, altijd up-to-date documentatie kan een besparing op het begrijpen van programmatuur gerealiseerd worden in de orde van 10-20%. Bij de keuze en implementatie van documentatiegeneratie kan men zich laten leiden door drie benaderingen die elk op basis van bronprogramma's tot daaruit afgeleide documentatie leiden: - Standaard commerciële tools met vaste functionaliteit: hierbij zijn geen aanpassingen mogelijk aan klantspecifieke wensen. - Dienstverlening waarbij de documentatiegeneratie uitbesteed wordt: hierbij kan de documentatie ook voor een deel handmatig gemaakt worden. - Aanpasbare documentatiegeneratoren: hierbij is de mate van automatisering het hoogst en kunnen klantspecifieke wensen het eenvoudigst gehonoreerd worden. Bij de keuze voor 'e'en van deze benaderingen moet men vooral letten op de ondersteuning van bedrijfsspecifieke idiomen en de aansluiting op het interne logistieke proces. De ideale situatie daarbij is dat zodra een bronprogramma naar de productie-omgeving overgedragen wordt deze automatisch ook naar een documentatie-server gestuurd wordt. Deze verwerkt het bronprogramma en meegestuurde extra informatie, en stelt de afgeleide documentatie direct beschikbaar via het Intranet. Na de selectie van de documentatiegenerator en eventuele aanpassing daarvan kan een begin gemaakt worden met de feitelijke invoering. Afhankelijk van de omvang (vaak tientallen miljoenen regels) kan in een periode van enkele dagen tot enkele weken de hele software-portfolio automatisch gedocumenteerd worden. Vanaf dat moment is de technische programmadocumentatie actueel. Door de koppeling aan het logistieke proces blijft deze ook actueel. Door de beschikbaarstelling via het Intranet is de toegankelijkheid van de documentatie ten slotte gegarandeerd. 5. Automatische programmatransformatie Naast analyses zijn ook programmatransformaties van belang. Deze kunnen gebruikt worden om de programmatuur zelf beter begrijpelijk te maken, om op die manier de kennis zoals verborgen in programmatuur beter te ontsluiten. Door goed management van de software-logistiek kunnen deze transformaties geautomatiseerd op de juiste momenten geactiveerd worden. Volledige automatisering van dergelijke migraties is essentieel om additionele testprocessen te helpen voorkomen. Het uiteindelijke doel van programmatransformaties is om bestaande programmatuur automatisch aan te passen aan de voortdurende evolutie van programmeertalen, technologie, en bedrijfsprocessen, en zo de in deze programmatuur aanwezige kennis beter inzichtelijk te maken. 6. Toekomstperspectief Een verstandige lange termijn strategie ten aanzien van software-logistiek heeft mede als doel de kennis zoals verborgen in bestaande software-systemen steeds beter toegankelijk te maken. Op deze manier hoeft software geen kennisprobleem te zijn, maar kan het juist een bijzonder nuttige kennisbron zijn. De gekozen aanpak richt zich op een geformaliseerde software-logistiek en de inzet van automatische documentatie en transformatie van programmatuur. Deze zorgen ervoor dat de in de systemen beschikbare kennis continu zo goed mogelijk beschikbaar is. Deze aanpak geeft uitzicht op een aanzienlijke verhoging van de kwaliteit en afname van kosten voor beheer en onderhoud van grote applicatieportfolios. ------------------------------------ OVER DE AUTEURS Jan Boef is Solution Integrator bij ABN AMRO in het aandachtsgebied Enabling. Hij draagt daar de verantwoordelijkheid voor de aanpak van software logistiek en maintenance. Arie van Deursen is projectleider bij het Centrum voor Wiskunde en Informatica. Paul Klint is themaleider bij het Centrum voor Wiskunde en Informatica en hoogleraar informatica bij de Universiteit van Amsterdam. De auteurs zijn gezamenlijk nauw betrokken geweest bij de configuratie en koppeling van een documentatiegenerator aan het logistieke proces van ABN AMRO. Eerder hebben zij samengewerkt in het Resolver onderzoeksproject op het gebied van systeemrenovatie. ------------------------------------ KADER "Documentatiegeneratie" Een documentatiegenerator analyseert programma's, en probeert daar zoveel mogelijk informatie uit te destilleren. Voorbeelden hiervan zijn: - Door welke programma's een bepaald programma wordt aangeroepen. - Tekstuele beschrijvingen over het doel van een programma. - Het gebruik van databases, copybooks, en bestanden. - Indexering van kernwoorden die in commentaar voorkomen. - Extractie van business-regels. De gevonden informatie kan, afhankelijk van het produkt, op diverse manieren bekeken worden varierend van proprietary browsers tot standaard Web-browser zoals Netscape of Internet Explorer. De getoonde informatie maakt de technische structuur van het software-systeem zichtbaar, om zo de daarin bevatte systeemkennis beter toegankelijk te maken. Deze kennis kan voor diverse doeleinden worden gebruikt, variërend van eerste kennismaking met een systeem (om de inwerktijd van nieuwe medewerkers te verkleinen) tot meer diepgaande pogingen een specifiek programma of sectie te begrijpen (geschikt voor impact-analyses bij beheer en onderhoud). Bovendien kan de getoonde informatie (zoals bijvoorbeeld metrieken) gebruikt worden voor het vormen van een kwaliteitsoordeel over de gedocumenteerde systemen. Er zijn verschillende benaderingen van documentatiegeneratie die op de volgende punten verschillen: - De ondersteunde talen (b.v. COBOL, CICS, JCL, SQL, enz.) - De mogelijkheid om eenvoudig talen of taaldialecten toe te voegen. - Het soort informatie dat wordt afgeleid uit de programmatuur. - De manier waarop informatie wordt weergegeven, zoals tekstueel of grafisch, en de mate van integratie tussen de diverse views. - Het abstractienivo van de afgeleide informatie. - De mogelijkheid om inhoud en vormgeving van de gegenereerde documentatie per gebruiker te definiëren. ------------------------------------ KADER "Programmatransformaties" Programmatransformaties hebben als doel om gegeven broncode te verbeteren. Voorbeelden hiervan zijn: - Het vervangen van verouderde taalconstructies door meer moderne varianten. - Het vervangen van aanroepen naar verouderde utilities. - Het moderniseren van de code door b.v. ongestructureerde statements zoals GOTO's te vervangen door gestructureerde statements. - Het consequent formatteren van de broncode. - Het systematiseren van commentaarconventies. Het doel van deze transformaties is om de leesbaarheid en de onderhoudbaarheid van de code te vergroten. Tools voor programmatransformaties verschillen op de volgende punten: - De ondersteunde talen. - De mogelijkheid om talen of taaldialecten toe te voegen. - De mogelijkheid om nieuwe verbeterregels toe te voegen. - De kwaliteit van de transformaties. Sommige systemen zijn gebaseerd op "oppervlakkige" tekstuele transformaties en kunnen daardoor de correctheid van de transformaties niet garanderen. Andere systemen baseren zich op syntactische transformaties en kunnen daardoor garanderen dat transformaties alleen toegepast worden op plaatsen waar dit wenselijk is. - De mate van automatisering van het hele transformatieproces. ------------------------------------ Bijlage: powerpoint met daarin Figuur 1: Software logistiek Figuur 2: Documentatiegeneratie