Naar een assemblagelijn voor software

Veel softwareontwikkelaars beginnen aan elke applicatie, alsof het de eerste in zijn soort is. En dat terwijl veel projecten heel wat gemeenschappelijk hebben in manier van werken en technische opbouw. Er kan dus best een en ander ‘gerecycleerd’ worden. In de praktijk kan je grote delen van het ontwikkelingsproces formaliseren en automatiseren met een resem tools die al dan niet goed samenwerken.

Vaak wordt een veralgemening van de ontwikkeling vergeleken met een assemblagelijn. Die vergelijking slaat niet op het maken van vele kopieën van het eindproduct, maar op het volgen van eenzelfde proces en hergebruik van componenten tussen verschillende projecten. Zo’n veralgemeend ontwikkelingsproces voor software noemen we een ontwikkelingsstraat.

De ontwikkelingsstraat steunt op het feit dat verschillende softwareprojecten binnen eenzelfde bedrijf vaak gelijklopende technische vereisten hebben. Je kan ze dan ook met eenzelfde architectuur ontwikkelen. De vereisten rond beveiliging, foutafhandeling, databasetoegang, lay-out en stijl van de schermen, opdeling in lagen of modules enzovoort, zijn vaak dezelfde.

Het grote verschil is de businesslogica die de applicatie moet realiseren. De strategie van ontwikkelingsstraten concentreert zich op wat de verschillende softwareprojecten gemeenschappelijk hebben, om een zo groot mogelijke meerwaarde te creëren. Anderzijds moet deze strategie voldoende fl exibel zijn om de verschillen zo effi ciënt mogelijk te beheren. De strategie legt het ontwikkelingsproces vast en automatiseert waar mogelijk de ontwikkeling.

Het gemeenschappelijke deel van nieuwe applicaties ontwikkelen als componenten en het variabele deel op basis van templates en designdocumenten, heeft een aantal voordelen. Zo is er een betere voorspelling van tijd, kwaliteit en kostprijs door minder specifi eke ontwikkeling en meer ervaring binnen het proces. Hergebruik is ook ingebakken in het proces, in plaats van unieke, ad hoc implementaties.

Een bijkomend voordeel is dat de applicaties gemakkelijker onderhouden kunnen worden, omdat ze allemaal op dezelfde manier zijn opgebouwd.

De ontwikkelingsstrategie bepaalt ook het proces waarin een teamlid een bepaalde rol opneemt en modellen, code en op te leveren documenten aanmaakt. De verantwoordelijkheden en de werkproducten van elk teamlid zijn dus vastgelegd.

De meeste bedrijven volgen al een bepaald proces, alleen is dit niet altijd als dusdanig gedocumenteerd. Door een proces te documenteren krijg je meer inzicht en kan je dat proces eenvoudiger optimaliseren en automatiseren.

PROCES FORMALISEREN EN AUTOMATISEREN
Het automatiseren van softwareontwikkeling kan je op dezelfde manier aanpakken als het automatiseren van om het even welk businessproces. Na het documenteren van het proces bekijk je welke stappen in aanmerking komen voor automatisering, en met welke tools.

Het soort project, de cultuur van het bedrijf en de beschikbare mensen beïnvloeden de keuze van het proces. Er kan vertrokken worden van een bestaand proces zoals het traditionele watervalmodel, van een meer iteratieve aanpak zoals het Rational Unifi ed Process of één van de agile methodes, die je steeds aanpast aan de noden van het team.

Een andere mogelijkheid is om de bestaande processen van vroegere projecten te evalueren en te combineren, om zo bijvoorbeeld tussentijdse werkproducten te elimineren als hun toegevoegde waarde klein is.

Daarna bepaal je welke stappen van het proces het meest in aanmerking komen voor automatisering. Productiviteits- en kwaliteitsverhoging zijn hierbij de doorslaggevende criteria.

Voor de ondersteuning van die stappen kan je een tool aankopen of, in mindere mate, zelf ontwikkelen. Bij de keuze van de tools is het belangrijk te kijken hoe configureerbaar en uitbreidbaar ze zijn. Op die manier verhinder je dat je het proces te veel moet bijsturen in functie van de tools.

Het proces aanpassen aan de tool is wel goedkoper dan omgekeerd, maar leidt waarschijnlijk tot een situatie die niet echt optimaal is. Toch valt het niet uit sluiten, en dan is het belangrijk dat het team verandering aanvaardt. Zo kan het zijn dat voor het automatiseren van bepaalde stappen de werkproducten uit voorgaande stappen meer detail moeten bevatten. Maar de verantwoordelijken voor deze werkproducten zien alleen meer werk voor hen. Ze zien niet de globale winst. Denk hierbij bijvoorbeeld aan codegeneratie, waarvoor de analysedocumenten voldoende detail en structuur moeten bevatten.

Elk softwareproject heeft zijn eigenheden. In plaats van te proberen alle mogelijkheden en behoeftes op voorhand te voorzien, kan je dan ook beter het proces iteratief implementeren. Pas door effectief gebruik leer je of de genomen keuzes correct zijn, en stuur je na iedere iteratie bij. Op die manier kom je stap voor stap en meer efficiënt tot de beste oplossing.

TOOLS IN DE MARKT
Enkele bedrijven hebben een portfolio aan tools die het volledige traject van softwareontwikkeling beslaan. Het aanbod omvat project management en rapportering, requirements management, analyse en design, version control, change request en defect management, test tools en natuurlijk een geïntegreerde ontwikkelingsomgeving. Dit heeft als voordeel dat de integratie tussen de tools vlot verloopt. Daar staat tegenover dat een bepaald proces al ingebakken zit in deze integratie en dat je dit proces moet volgen om de grootste meerwaarde te realiseren. Daarbij moet wel vermeld worden dat sommige tools custom templates toelaten om beter aan te sluiten bij het bestaande proces.

Het gebruik van UML als modelleringstaal zorgt ervoor dat modellen in elk businessdomein en voor elke architectuur toepasbaar zijn, wat tegelijk ook een nadeel is. Die flexibiliteit kan je best inperken door regels te definiëren die een manier van werken, geschikt voor een bepaalde context, vastleggen. Een andere manier om dit op te vangen is het gebruik van domeinspecifieke talen (DSL) die snelle ontwikkeling mogelijk moeten maken binnen een specifiek domein. Deze aanpak wordt onder andere ondersteund door de Visual Studio omgeving van Microsoft.

Het bekendste voorbeeld van end-to-end ontwikkelingsondersteuning is waarschijnlijk het Rational gamma van IBM. Aan het andere uiteinde van het spectrum staat de doe-hetzelfstrategie. Je stelt een ontwikkelingsstraat samen uit verschillende losse tools die het meest geschikt lijken. Het integreren van deze tools zal een grote uitdaging zijn, maar het geheel is wel aangepast aan het gewenste proces. CollabNet, bijvoorbeeld, is een samenstelling van verschillende openbrontools die geïntegreerd zijn met populaire IDE’s.

IN DE PRAKTIJK
Voor elk onderdeel in softwareontwikkeling bestaan verschillende tools die al dan niet goed samenwerken. Om de ontwikkelingsstraat zo soepel mogelijk te laten verlopen is het belangrijk om de tools goed op elkaar af te stemmen. Op die manier kan de output van een voorgaande stap als input dienen voor de volgende stap. Als voorbeeld lichten we de automatisering toe van enkele stappen:

– In de analysefase maak je op basis van de algemene requirements modellen die na verfijning voldoende duidelijk moeten zijn om te implementeren. Tot nu toe werden analyses vaak in documenten beschreven. Door de analyse in een formeel model te gieten, kan je richtlijnen rond het opstellen van de analyse automatisch controleren. Een model kan dan ook als basis dienen om code automatisch te genereren.

– De ontwikkelingsfase is in de meeste gevallen al de meest geautomatiseerde fase, omdat die zich er het beste toe leent. Ontwikkelaars beschikken over geavanceerde IDE’s die een snelle ontwikkeling toelaten. In een verder gevorderd proces is gedefinieerd hoe de verschillende elementen van de analyse passen in de gekozen technische architectuur. Deze definities omzetten naar code kan ofwel geautomatiseerd gebeuren, ofwel manueel, met ondersteuning van richtlijnen en templates. Door het genereren van de co
de speel je sneller in op een veranderende analyse of op wijzigingen in de architectuur. Het eerste heeft enkel een opnieuw genereren van de code als gevolg, het tweede een aanpassing in de transformatie, waardoor je ook de al gegenereerde code up to date brengt.

– Automatiseren van testen zorgt ervoor dat je testen vaker kan uitvoeren, wat een vroegere foutdetectie en betere kwaliteit oplevert. Tijdens de testfase maakt integratie tussen de tools het mogelijk om bij het rapporteren van een bug terug te verwijzen naar de desbetreffende functionaliteit. Bij het oplossen van een bug link je de codewijzigingen aan het bugrapport.

Door code te bewaren in een versiebeheertool en continu te integreren en testen op een build server, hou je de kwaliteit onder controle. Elke aanpassing van een ontwikkelaar wordt automatisch getest, niet enkel op functionaliteit maar ook op het volgen van de richtlijnen, zodat je fouten snel detecteert. Indien een versie voor alle automatische testen slaagt, gebruik je die versie voor verdere manuele testen en de uiteindelijke productieversie. Door het gebruik van versiebeheer, achterhaal je welke versie van de applicatie productief is en met welke code en analyse deze overeenstemt.

Om softwareontwikkeling op een efficiënte manier ten dienste te stellen van de business moet je het dus proces continu verbeteren en automatiseren. Op deze manier kan de business snel inspelen op de veranderende markt.

Jeroen Wyseur is technical architect bij AE NV.