One Shoe (part of iO)

Lifecycle management: hoe behoud je de kwaliteit van software ontwikkeling in een veranderend IT landschap?

Dit artikel is onderdeel van een blog serie over in's & out's voor een strategische en succesvolle Enterprise software development. In het eerste artikel hebben we het gehad over de verschillen tussen built for purpose en built to last software en waarom dit zo belangrijk is voor een succesvol ontwikkelingsplan om software te creëren. In dit artikel gaan we het hebben over de aanpak van lifecycle management van software ontwikkeling projecten om de kwaliteit van de software in een veranderend IT landschap de waarborgen.   

Tibor Uittenbogaard | 04 dec 2018

Bij One Shoe hebben we veel ervaring met software ontwikkeling en specialiseren we ons in de complexe(re) projecten. Dit zijn veelal projecten waar bij ‘maatwerk code’ om de hoek komt kijken. Bij de projecten met maatwerk software, systeemintegraties, enterprise level content management, en bedrijfsprocessen met meerdere stakeholders, weten we dat de software oplossing zal (moeten) evolueren in de loop der tijd. Als er meer dan één doel moet worden bereikt met de oplossing, en als die doelen in de loop der tijd gaan evolueren, dan is een strategie vereist om de kwaliteit en duurzaamheid te kunnen waarborgen, in alle stadia van het project.

Maar als het gaat om het ontwikkelen van content management systemen of software op enterprise niveau gaat één focusgebied een groot verschil maken; het beheersen van de software levenscyclus (life cycle). Levenscyclus management en kwaliteitsbeheersing zijn minder complex als een software ontwikkelproject klein is, en als het project gefocust is op het leveren van een simpele oplossing voor een specifiek probleem, of voor een korte periode.

Built- to- last lifecycle management

Bij het ontwikkelen van ‘built to last’ software zijn de technische aspecten (veranderingen van technische requirements en software architecturen die daarin mee kunnen gaan), slechts een onderdeel van het spel. Enkel het goed, kwalitatief en professioneel beheersen van requirements (wensen en eisen), specificaties en scope (hoeveelheid werk), is niet afdoende voor het handhaven van kwaliteit gedurende de gehele applicatie-levenscyclus van software oplossingen die lang mee moeten gaan. Want zelfs als de opdrachtgever en het bureau een ontwikkelplan (roadmap) kunnen vaststellen die een paar jaar vooruit bevroren kan worden , dan nog zijn veranderingen onvermijdelijk.

Denk bijvoorbeeld aan veranderingen in je (ontwikkel) team, in het team en de beïnvloeders en beslissers aan de klantzijde, en in de bedrijfsdoelstellingen. Een minder voor de hand liggende maar een minstens zo belangrijk factor is de verminderende waarde van software oplossingen. Wanneer goedkopere en gelijkwaardige of betere alternatieven op de markt komen is het meer dan ooit van belang onderscheidend te zijn en toegevoegde waarde te bieden. Kwaliteitsbeheersing in de levenscyclus van de software en wendbaar zijn waar het gaat om de onderliggende processen, kan hét onderscheidende punt zijn waarmee het verschil wordt gemaakt.

Het menselijke aspect achter enterprise level software ontwikkeling

Vanaf het eerste begin moet het bureau of de ontwikkelpartij rekening houden met veranderingen in de samenstelling van het eigen team, en het team aan de klantzijde (de stakeholders). Dit - rekening houdend met het menselijke aspect dat zo’n belangrijke rol speelt bij de ontwikkeling van enterprise level software - is de sleutel tot succes, waar het gaat om lange termijn software ontwikkeling.

Laten we bijvoorbeeld beginnen met aan te nemen dat veranderingen in het ontwikkelteam onvermijdelijk zijn. En voeg daaraan de groeiende complexiteit van het IT-landschap, systemen, source code, technische specificaties en bedrijfsdoelstellingen toe. En maak het af met een gezonde dosis wijzigende beslissers en beïnvloeders aan de klantzijde. Het is hiermee overduidelijk dat voorbereid zijn op deze veranderingen belangrijk is.

Omdat deze veranderingen onvermijdelijk zijn, worden versiebeheer, documentatie, kennisdeling en kwaliteitsborging, broodnodige operationele en niet-onderhandelbare vereisten, die zwaarder wegen dan functionele of technische vereisten, (bedrijfs)doelstellingen en ontwerpen.  

Programma's van eisen, bedrijfsdoelstellingen en design

Wensen, eisen en specificaties (zowel technisch als functioneel) en design zijn belangrijk bij software ontwikkeling. Dat zal ik zeker niet ontkennen. Toch staan deze factoren bij mij op de tweede plaats. Want de specificaties, eisen, designs, het product backlog en de ontwikkelplannen zijn momentopnamen. Deze zullen met het project mee veranderen. Op de eerste plaats is het van belang dat er processen zijn geïmplementeerd die borgen dat die veranderingen op ieder moment kunnen worden beheerst, zonder verlies van kwaliteit.

Waarborging van kwaliteit in een evoluerend ontwikkelproject, verzekert het project en de opdrachtgever uiteindelijk van terugkerende waarde voor de investeerder (return on investment) en een kwalitatieve software oplossing die vele jaren mee kan gaan. Het starten van een project voor de ontwikkeling van een enterprise-level content management- of software systeem dient daarom te starten met een gedegen ontwikkel- en levenscyclus-beheersingsplan. Althans, als de applicatie bedoeld is om jaren mee te kunnen gaan. En wat mij betreft vereist dat levenscyclus-beheersingsplan, allereerst: test coverage.

Topics:

Naast functionele en analytische cookies gebruikt One Shoe ook additionele cookies. Vind je het goed als we deze plaatsen?