IK, negende jaargang, nummer 5, 2010 7

Kennis in tekst vertoont parallellen met de hiëro-gliefen van de oude Egyptenaren. Opschrijven kost veel tijd en het resultaat is vaak moeilijk te begrij-

pen. Software engineering heeft echter nog steeds een ba-sis in specificaties welke voornamelijk zijn vastgelegd in tekst. Omdat gevraagde functies met de dag complexer worden, is de overstap naar kennisgebaseerd werken in het software-ontwikkelproces een welhaast onvermijde-lijke.De IT-functie is relatief duur, de doorrekening van deze kosten naar consumenten eindig en het opschuiven van IT richting de business is onontkoombaar. Naast consoli-deren, standaardiseren en stroomlijnen van de IT-infra-structuur – datacenters, netwerken en software tools – heeft IT een taak in het orkestreren van de heterogene verzameling IT-applicaties in de architectuur. Naast een optimale beveiliging en ontsluiting van data en informa-tie, een gefaseerde afrekening met legacy en slimme uit-besteding van beheerstaken, spelen ook de cloud, SaaS en webservices een belangrijke rol. In steeds kortere cycli vraagt de business om nieuwe toepassingen: steeds meer online, fluïde, foutloos en flexibel.

IT-afdelingen zitten ingeklemd tussen enerzijds sales, marketing en business analisten en anderzijds ontwikke-laars, programmeurs en testers. Softwarespecificaties vor-men de vertaalslag van business naar software. Specifica-ties zijn echter zelden zo opgeschreven dat ze in een keer helder en begrijpelijk zijn voor deze doelgroepen. Wanneer de softwaremakers in het buitenland zijn gevestigd (off-shore), zijn communicatie en overleg ‘majeure’ activitei-ten – want in India weten ze uiteraard niet altijd wat ze precies met die aangeleverde specificaties moeten doen. Soms komen de ontwikkelaars naar Nederland (onsite) of maken ze gewoon deel uit van de interne IT-organisatie. Ook dan moet er veel gepraat worden. Communicatie is natuurlijk wel als olie in een machine, maar onduidelijke specificaties leiden tot een enorme omhaal. De impact van ambiguïteiten, inconsistenties en onvolledigheden in spe-cificaties op de totale keten van softwareontwikkeling is aanzienlijk. Het beïnvloedt het technisch design, de pro-grammatuur en het testen en uiteindelijk ook het functio-neren van de software in operatie. ‘Maintenance’ wordt dan vaak ‘redesign’ op codeniveau! Daarmee houden we in het software engineering proces complete legers van

‘stakeholders’ aan het werk. Met het beschrijven van werkprocessen, procedures, scripts, werkinstructies en functies creëren zij een enorm volume aan naar elkaar verwijzende documenten. Het leidt tot grote aantallen workarounds. Dit kan echt anders... beter, sneller en goedkoper.

Geschreven tekst is vaak niet de beste techniek om kennis vast te leggen. Met name daar waar het gaat om het hel-der weergeven van complexe relaties tussen variabelen, waarbij de zo belangrijke toetsing op volledigheid, consis-tentie en juistheid aan de orde is. Vanaf een bepaalde complexiteitsgraad is de transparantie van tekst simpel-weg te gering. Formele(-re) technieken zijn dan nodig. Zoals grafen, finite state machines, state transition dia-grams, petri-netten en flowcharts. We moeten hier wel goedgekozen eisen aan stellen. Bij de populaire flowcharts bijvoorbeeld ontbreekt het aan een wiskundige basis: de ‘traceability’ is gering en het wijzigen van een flowchart is arbeidsintensief.

Een kennisgebaseerd paradigma is nodig: weten welke eisen je moet stellen voor een adequate keuze van tech-nieken voor softwarespecificatie. Doelgerichtheid, trans-parantie, directe bruikbaarheid en wijzigbaarheid van de specificaties zouden daarbij voorop moeten staan. Alleen dan kunnen we voorkomen dat de business, testers en de programmeurs de ontcijfer-capaciteiten van een Champollion moeten bezitten om de specificaties te begrijpen.

Workaround

Lucardie

Prof. dr. Larry Lucardie is CEO van

Knowledge Values

(Larry.lucardie@knowledge-values.com)