Software-onderhoudbaarheid is een moeilijk te grijpen ‘non-functional requirement’. Er zijn dappere pogingen om grootheden te vinden die meetbaar zijn en een indicatie geven van de onderhoudbaarheid. De fundamentele aanpak voor goede onderhoudbaarheid zit dieper en biedt uitdaging voor zowel de ontwikkelgemeenschap als de afnemende partijen.
De onderhoudsfase is de langste fase in de levensduur van een applicatie, soms zelfs langer dan de technologielevensduur. Door zijn lengte is deze fase in totaal de kostbaarste fase van het softwareleven. Het is dus vreemd dat software-onderhoud niet wordt onderwezen in de opleidingen, noch dat het in software life cycles of kwaliteitssystemen is ingebouwd. Na enkele decennia software produceren moeten we dus concluderen dat goed onderhoudbare software eigenlijk gewoon ‘ontstaat'.
De onderhoudbaarheid van software is een moeilijk grijpbare eigenschap (van de ISO9126 attributen het moeilijkst te vatten). Echter, zoals een schaakgrootmeester een goede van een kansloze stelling direct weet te onderscheiden kan een ervaren programmeur direct ‘slechte' van ‘goede' software onderscheiden. Dit is wat Robert Pirsig in zijn fameuze boek ‘Zen and the Art of Motorcycle Maintenance' beschrijft: 'kwaliteit is gewoon wat iemand bevalt'. Het oog van de meester ziet in het eindresultaat of het product is gemaakt met visie en passie of dat het duidelijk gebrek daaraan uitademt.
Het ‘inbouwen van softwareonderhoudbaarheid' is uitdagend wegens de fundamentele verschillen tussen ontwikkelaars en onderhouders. Systemen worden gemaakt door ontwikkelaars, die willen ontwikkelen, innoveren en nieuwe technologieën exploreren. Onderhouders hebben deze prioriteiten omgedraaid: dus alleen innoveren en overgaan op nieuwe technologieën als het hoogst noodzakelijk is. Dit is niet typisch software gerelateerd: Een motorfiets-onderhoudsmonteur zal het wel uit zijn hoofd laten om een monoveer achtervork op uw BMW uit 1945 te monteren. Het hangt op een consistent tot in de kleinste details met een bepaalde mindset geconstrueerd product dat door een competente onderhoudsmonteur wordt ‘gelezen'.
Kortom, er ligt een uitdaging voor de ontwikkelgemeenschap om expliciet onderhoudbaarheid in te bouwen door passie en visie in hun producten te leggen. Het aanstellen van een architect als ‘keeper of the vision' is niet genoeg. ZHij/zij moet in staat worden gesteld deze visie door te managen in het eindresultaat. Voor de afnemende partijen is er de uitdaging om (ondanks de tegenwerkende aanbestedingsregels) visie en passie te (h)erkennen en te waarderen. Ze zullen er veel mee kunnen verdienen.
Als student zojuist een vak gevolgd dat hier enige aandacht aan besteed. Software onderhoud valt zeker in een reeks modellen terug te vinden in een scala aan vakken; maar geheel gelijk dat hier in de opleidingen te weinig aandacht aan wordt besteed.
Met het voorspellen van maintainability is het niet veel beter gesteld. Er zijn teveel factoren; complexiteit, omvang, welke tooling, aantal belanghebbenden, gedrag klant, etc. Omdat we het eigenlijk niet voorspellen fiedelen we er omheen; jouw quote van Robert Pirsig vind ik daar symptomatisch voor.
Bij het kopen van een huis hebben de kopers eigenlijk alleen oog voor de bouwkosten; wie rekent uit wat de onderhoudskosten zijn van een rieten dak, pannen of een plat dak? De architect? Nee, dat is zijn specialisme niet. De aannemer? Die willen alleen maar bouwen. De klusjesman die het zal onderhouden? Die schakel je pas later in. De enige constante factor in dit verhaal is de klant; de klant zal expliciet moeten vragen om deze kosten om een cultuuromslag te veroorzaken.
Nu vervult een IT club vaak meerdere, of alle, van de genoemde functies en je hebt geheel gelijk in te stellen dat deze functioneren als aparte werelden. Hoe ver ze principieel ook uit elkaar mogen liggen, beide kampen hebben rationele argumenten en daar moet zeker consencus in te vinden zijn. Maar waarom moeilijk doen als je er met het vermelden van een onderhoudstarief ook al bent? Al helemaal als we het niet goed kunnen meten?
I.p.v. een visie/passie te overleggen moet het proces voorspelbaarder worden en dit communiceren naar de afnemende partij.
De meeste ontwikkelaars willen alleen de software onderhouden die ze ooit zelf ontwikkeld hebben. Als die ontwikkelaar dan opstapt dan heb je als onderneming een serieus problem en ben je genoodzaakt om de markt af te zoeken naar een partij die wèl wijzigingen wil aanbrengen in de reeds ontwikkelde applicaties. Soms is men zelfs genoodzaakt de applicaties vroegtijdig af te schrijven en nieuwe software te implementeren!
Door ontwikkelaars wordt er ook vaak neergekeken op onderhoudswerkzaamheden. “Prutsen in andermans code” is niet erg populair en onderhouden van software is veel minder hip dan het ontwikkelen van nieuwe software met de nieuwste tools. Je moet dus echt van het oude ambacht houden om de programmacode van andere ontwikkelaars te onderhouden en te verbeteren. Alleen de beste ontwikkelaars zijn hiertoe in staat !!
Als beheer/ontwikkelafdeling moet je dus beschikken over ontwikkelaars met passie voor programmeren.
Arno van Unen
Software Onderhoud Nederland BV
Het uit de agile wereld bekende “pair-programming” kan hier een grote bijdrage in leveren.
Doordat er altijd iemand meekijkt wordt je (tot op zekere hoogte) verplicht je code dusdanig te maken dat een ander het ook begrijpt. Dit kan helpen bij onderhoud achteraf doordat er enigszins aandacht is besteed aan de leesbaarheid van de code.
Wel is het zaak dat de “pair” regelmatig rouleert. Als je constant met dezelfde pair programmeert, raak je gewend aan elkaars “taal” en stijl, en zal de aandacht voor leesbaarheid mogelijk verslappen
Wij passen zelf altijd “peer-to-peer” reviews toe waarbij de ene ontwikkelaar het werk van een andere ontwikkelaar controleert a.d.h.v een checklist. Pas als alle eventuele tekortkomingen opgelost zijn mag de software voor test en acceptatie worden aangeboden.
De eindproducten worden op die manier op verschillende aspecten gecontroleerd: programmacode, documentatie, gebruiksgemak, verificatie t.o.v. specificaties, etc.
Deze methode helpt om het fouten te reduceren en de kwaliteit (aanzienlijk) te verbeteren.
Arno van Unen
Software Onderhoud Nederland BV