De praktijk stelt steeds hogere eisen als het gaat om de kwaliteit, betrouwbaarheid en vooral de kosten voor ontwikkeling, exploitatie en beheer van software. De vraag is hoe uw ICT-organisatie gevolg kan geven aan de gestelde eisen. In de ViNT-publicatie ‘Wie niet snel is moet slim zijn’ wordt een nieuwe kijk gegeven op productiviteit van software ontwikkeling. De boodschap van dit boek is procesbeheersing. Alleen als we het proces van software-engineering en -productie structureel verbeteren, kunnen de prestaties significant worden verbeterd. Anders gezegd, als wij als automatiseerders ons proces niet beter leren beheersen, dan is ieder verbeteringsinitiatief bij voorbaat gedoemd tot mislukken. Eventuele verbeteringen die anders toch worden behaald, zijn eerder toe te schrijven aan toevalstreffers of de bovengemiddelde inzet van individuen dan aan goed doortimmerde, fundamentele verbeteringsinitiatieven.
Het gaat er niet om dezelfde dingen beter en sneller te doen, maar juist om andere, slimmere dingen te doen. En dat is waar procesmatig ontwikkelen om de hoek komen kijken.
Procesmatig ontwikkelen
De kern van procesbeheersing binnen software engineering is terug te vinden in het concept van procesmatig ontwikkelen. Hierbij zijn de activiteiten vooral gericht op het vaststellen, borgen en continu verbeteren van de software ontwikkelingsmethodiek. Dit gebeurt onder andere door het inrichten van een gedefinieerd ontwikkelingsproces, verregaande standaardisatie en de implementatie van een kwaliteitssysteem. Door de continue verbetering wordt opgedane ervaring geïnstitutionaliseerd en later gedisciplineerd hergebruikt.
Door duidelijke processtappen te definiëren en te hanteren wordt herhaalbaarheid in het ontwikkelingsproces gebracht.
Door duidelijke processtappen te definiëren en te hanteren (vooral dit laatste vormt vaak nog een uitdaging) wordt herhaalbaarheid in het ontwikkelingsproces gebracht. Hierdoor ontstaat de mogelijkheid gerichte verbeteringen aan te brengen in het proces, met voorspelbaar eindresultaat. Voorwaarde is wel dat binnen het gehele ontwikkelproces objectieve en duidelijke meetpunten worden aangebracht. Het uiteindelijke doel is het verhogen van de productiviteit.
Een tweede belangrijke factor is verregaande standaardisatie van hulpmiddelen, talen, platforms, technologieën en methodieken. Denk hierbij aan de keuze voor één à twee platformen of specifieke technologieën zoals web-based user interfaces. Een keuze maken is veelal niet het moeilijkste onderdeel; je als organisatie hieraan committeren wel. Een gemaakte keuze hoeft namelijk niet altijd de meest optimale oplossing te bieden voor ieder probleemgebied. Aan de andere kant vormt het managen van een veelvoud aan platforms vaak een grotere uitdaging wat tot uiting komt in de kosten voor exploitatie en beheer.
Een derde factor is het, voor alle fasen binnen het ontwikkelproces, inrichten en onderhouden van een kwaliteitssysteem. Hierdoor wordt meer inzicht verkregen in de kwaliteit van het eindresultaat en het daarvoor doorlopen proces. Ook hier is het belangrijk meetpunten aan te brengen en op basis van de resultaten stapsgewijs verbetervoorstellen te introduceren. Belangrijke vragen hierbij zijn hoe fouten/onvolkomenheden tot stand zijn gekomen en hoe we deze situaties in de toekomst kunnen vermijden. Dit kan weer leiden tot aanpassing van het ontwikkelproces, het bijstellen van standaarden of het gebruik van andersoortige methodieken. Het uiteindelijke doel is het verhogen van de kwaliteit.
Naast een steeds grotere noodzaak biedt procesmatig ontwikkelen unieke voordelen. De implementatie maakt het mogelijk daadwerkelijke rendement te behalen uit een lerende IT-organisatie. Het delen van kennis en best practices wordt eenvoudiger door het gezamenlijke vertrekpunt en opgedane ervaringen worden door regelmatige evaluatie geborgd in het ontwikkelproces. Daarnaast wordt de organisatie minder afhankelijk van de individuele kwaliteiten van medewerkers en kunnen medewerkers flexibeler worden ingezet op projecten. Uiteindelijk met als resultaat kwalitatief betere en meer betrouwbare software ontwikkelt met een hogere productiviteit.
Ontwikkelstraten
Procesmatig ontwikkelen wordt momenteel voornamelijk toegepast binnen ontwikkelstraten. Met ontwikkelstraten bedoelen we een ontwikkeleenheid waarbij de bemensing los is gekoppeld van de projecten; zij werken aan gespecificeerde werkeenheden die binnen de ontwikkelstraat zijn onderkend. Daarnaast is er een scheiding tussen de verantwoordelijkheid voor de software ontwikkeling en de evaluatie van het proces en de kwaliteit.
Een basis voor de inrichting van een ontwikkelstraat is de vorming van een Centre of Excellence. Hierbij wordt kennis gebundeld binnen één afdeling of groep medewerkers, vindt verregaande standaardisatie plaats en wordt een algemeen kwaliteitssysteem geïmplementeerd. Een volgende stap richting een ontwikkelstraat zijn service pools. Hierbij worden ‘flex-teams’ ingericht, waarbij nog op projectmatige basis wordt ontwikkeld, maar individuen flexibeler kunnen worden ingezet. De laatste stap richting een ontwikkelstraat is de implementatie van procesmatig ontwikkelen en het loskoppelen van de bemensing aan projecten.
Één van de grootste problemen van projectmatig ontwikkelen is dat hergebruik nauwelijks optreedt.
Één van de grootste problemen van projectmatig ontwikkelen is dat hergebruik nauwelijks optreedt. Dit is vooral te wijten aan de tijdsinspanning en/of investering die het aanschaffen, generiek maken en onderhouden van softwarecomponenten met zich mee brengen. Hoewel het (her)gebruik van softwarecomponenten voor één project vaak niet rendabel is, kunnen op organisatieniveau behoorlijke besparingen worden geboekt wanneer de kosten van componenten over meerdere projecten kunnen worden gedeeld, zowel gedurende de ontwikkeling als tijdens de exploitatie en het beheer.
Binnen een ontwikkelstraat is het proces van hergebruik ingebed en wordt op meer analytisch niveau gekeken naar mogelijkheden van hergebruik. Laten we als voorbeeld eens kijken naar een datumroutine voor een hypotheekapplicatie. Allereerst wordt gekeken welke andere datumroutines beschikbaar zijn, zowel intern als extern (abstractie). Indien de routine onderdeel uitmaakt van een grotere component, bijvoorbeeld een annuïteitenberekening, wordt gekeken of deze intern dan wel extern te verkrijgen is (synthese). Als laatste wordt gekeken of dit onderdeel specifiek voor deze applicatie ontwikkeld moet worden of toch generiek als component, zodat het ook in toekomstige applicaties kan worden ingezet (generalisatie). Met een kosten/baten berekening komt men vaak tot andersoortige conclusies dan wanneer een onderdeel op projectmatige basis zou worden ontwikkeld.
Met de scheiding tussen projecten en ontwikkelstraten, waarbij vanuit een project werk uitbesteed wordt aan een (interne) ontwikkelstraat, wordt meer grip op en stabiliteit van het ontwikkelproces verkregen. Binnen de ontwikkelstraat wordt een intake uitgevoerd op de gewenste functionaliteit, waarbij gekeken wordt in hoeverre specificaties impact hebben op het ontwikkelproces. Wanneer de gevraagde functionaliteit een te hoge mate van impact op het ontwikkelproces heeft, kan besloten worden deze alsnog in projectverband te ontwikkelen waarbij componenten door de ontwikkelstraat worden gerealiseerd. Wijzigingen in de grondslagen van een ontwikkelstraat kunnen namelijk meer kosten met zich meebrengen dan delen van applicatieontwikkeling projectmatig uitvoeren.
Verder resulteert een ontwikkelstraat in betere capaciteitsplanning. Een belangrijke oorzaak hiervoor is dat medewerkers niet aan projecten zijn gekoppeld, waardoor een verhoogde flexibiliteit ontstaat. Daarnaast ontstaat door het meet- en evaluatieproces meer inzicht in persoonlijke productiviteit en wordt daar in het toewijzingsproces van werkeenheden rekening mee gehouden. Tot slot kan specifiek noodzakelijke kennis gerichter worden ingezet, waardoor meer rendement wordt gehaald uit de aanwezige specialisten.
Tot slot
De noodzaak en het rendement van ontwikkelstraten wordt steeds meer zichtbaar; het inrichten en onderhouden ervan is echter een complex en langdurig proces. Naast het evolutieproces en de daarbij behorende investeringen, moet ook de organisatie leren omgaan met deze nieuwe manier van software ontwikkeling … maar het eindresultaat mag er zijn.
Marco de Jong
Sogeti Nederland B.V.
Business Development Engineering & Projecten