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.
This article is exclusively available to premium members of Bits&Chips. Already a premium member? Please log in. Not yet a premium member? Become one for just €20 for the first year and enjoy all the benefits.