(On)balans

16 juni 2010

Een van de onderwerpen die ik afgelopen najaar tijdens de Practical Product Lines-conferentie de revue heb laten passeren, was het ondersteunen van meerdere hardwareconfiguraties vanuit één softwarepakket. Dit bracht een interessante discussie teweeg die ik afgelopen jaren meerdere malen voorbij heb zien komen: wat is een goede balans tussen het aantal software- en hardwareconfiguraties binnen een productfamilie? Vanuit configuratiemanagement heeft het zo zijn voordelen als hetzelfde softwarepakket alle configuraties binnen dezelfde familie kan bedienen. Er is maar één pakket dat we hoeven te managen, en bij ieder product kunnen we dezelfde set software meeleveren.

Deze aanpak heeft echter ook een keerzijde. Voor ieder stukje code dat wordt aangepast, moeten we een impactanalyse doen van welke configuraties wel en niet worden geraakt, en daarmee wat we allemaal moeten testen. Dit kan in sommige gevallen leiden tot onaangename verrassingen. Door keuzes in het verleden kan het voorkomen dat het niet mogelijk is nieuwe functionaliteit te implementeren die op alle configuraties werkt. Dit kan zelfs leiden tot een ‘breuk’ in het softwarepakket. Naarmate de productfamilie groter wordt, groeit de kans op dit soort breuken, en wordt het analyseren van de impact nagenoeg onmogelijk.

Na verloop van tijd besluiten we dan vaak het roer om te gooien, omdat we het beheer van de productfamilie niet meer kunnen behappen. In de meest extreme gevallen volgt er dan een ommezwaai naar het andere uiterste: voor iedere systeemconfiguratie creëren we een eigen softwareproduct. Voor testers is dit in zekere zin een zegen. Bij een wijziging in de software hoeven zij alleen maar die ene configuratie opnieuw te testen. Ook de impactanalyse van wijzigingen is vele malen eenvoudiger dan in voorgaand scenario.

Maar ook deze manier van werken heeft zijn keerzijde. Vanuit softwareconfiguratiemanagement betekent het namelijk dat we veel parallelle lijnen zullen moeten onderhouden. Wanneer er ook nog relaties zijn tussen deze parallelle lijnen (vanwege hergebruik van code) lopen we ook hier tegen een probleem aan. Een bug in de code kan namelijk leiden tot nieuwe releases van alle producten die deze code hergebruiken. Het alternatief is geen hergebruik van code toestaan, maar dat is soms weer inefficiënt. Ook bij het managen van de configuraties introduceert deze aanpak extra werk: ieder product kent zijn eigen software, die we apart moeten beheren en administreren.

De waarheid zal ergens in het midden liggen. Om die te vinden, moeten we bij de decompositie van systemen niet alleen kijken naar de software, maar ook naar de configuratiemanagement– en testaspecten. Zeker zo belangrijk is het om de gemaakte keuzes te monitoren en er op (bij) te sturen indien nodig. Vaak bedenken we een geweldige architectuur om ‘de waarheid’ te ondersteunen. Door tijdsdruk, nieuwe inzichten en slecht monitoren van gemaakte keuzes zien we na verloop van tijd echter toch vaak weer een onbalans ontstaan.

Pascal van Kempen

Terug naar overzicht