Modellering och användning av produktlinjevariabilitet sid 6. Gemensam hårdvaruplattform. produktvarianter sid 14

Transkript

1 ntimeger INSIKT I TID T E M A : V Ä X M E D P R O D U K T F A M I L J Nr 1 mars 2004 Modellering och användning av produktlinjevariabilitet sid 6 Gemensam hårdvaruplattform för olika produktvarianter sid 14 Inkrementell utveckling av produktlinjer sid 16

2 Innehåll OnTime ska ge insikt i tid OnTime är en branschtidning som tar upp olika aspekter och nyheter inom området utveckling av inbyggda realtidssystem. OnTime ska ge möjlighet att ställa olika perspektiv mot varandra, och samtidigt visa helheten i teknikoch samhällsutveckling. Redaktion Ansvarig utgivare Christer Hoberg, vd Redaktionsråd Göran Carlzon, Erichs Communications Anders Magnusson, Göteborg Per-Ola Malm, Malmö Magnus Ohlsson, Malmö Michael Petersson, Linköping Redaktör Eva Holmquist, Jönköping eva.holmquist@combitechsystems.com Nätvariant av OnTime Ledare...3 Väx med produktfamilj Hur man behåller kontrollen över produktfamiljen...4 Modellering och användning av produktlinjevariabilitet i fordonssystem...6 AudioDev möter snabb teknikutveckling med flera produktvarianter...12 Gemensam hårdvaruplattform för olika produktvarianter...14 Inkrementell utveckling av produktlinjer...16 Jönköping (lokalkontor:växjö, Ulricehamn) Box Jönköping Tel Fax Malmö Box Malmö Tel Fax Göteborg (lokalkontor:trollhättan) Mölndalsvägen 30C Göteborg Tel Fax Stockholm Box Stockholm Tel Fax Linköping (lokalkontor: Örebro) Teknikringen 9 SE Linköping Tel Fax E-post info@combitechsystems.com Vårt område är inbyggda system.vi kommer aldrig att gå utanför detta område och måste därför behärska utveckling av inbyggda system bättre än någon annan. Våra uppdragsgivare kallar in oss när de ska gå in på nya teknikområden, effektivisera sina arbetssätt eller behöver hjälp med att förstärka sin utvecklingsverksamhet genom outsourcing eller skickliga utvecklare. Affärsidén bygger på att tillföra våra kunder kunskap inom systemutveckling och verka som en kunskapsförmedlare mellan de branscher som vi är verksamma i, det vill säga fordons-, telekommunikations-, medicinteknik-, industri- och försvarsbranschen.vår målsättning är att vara ledande inom vår nisch. Under de tolv år vi varit verksamma har vi etablerat oss nära våra kunder för att ge dem hög service. Hemsida Produktion Erichs Communications AB, Linköping Grafisk design PO.Annonsbyrå AB Tryck NRS-Tryckeri 2 Nr 1 Mars 2004

3 LEDARE Produktfamiljtänkande att klara sig med 21 personer istället för 120 De flesta produkter finns i flera varianter, anpassade mot kundernas olika behov av funktionalitet, egenskaper och pris. Om man tar tillvara det faktum att varianterna har stora gemensamma delar finns det stora pengar att tjäna, ledtider att korta och kvalitet att vinna genom effektivare och säkrare utveckling, underhåll och vidareutveckling av varianterna. Så småningom inser man att man har ett dussin produkter där 90 procent borde vara gemensamt, men där man tvingas underhålla och vidareutveckla alla var och en för sig. Det vill säga istället för att ha nio personer som underhåller det gemensamma och en person på varje specifik del = 21 personer, så har man tio personer på varje del = 120 personer! Man är alltså ganska ineffektiv. Detta uppnås genom följande två principer: Utveckling, underhåll och test på gemensamma delar görs bara en gång, inte för alla varianter. Utveckling, underhåll och test av en specifik variant görs bara på skillnaden till det gemensamma. Ovanstående kan tyckas självklart, men faktum är att man sällan hanterar varianter av en produkt så här, utan tvärtom hanterar varianter som om de var helt olika produkter. Anledningarna till detta är många men här är ett vanligt, kanske aningen tillspetsat scenario: En produkt utvecklas först som just en produkt. Än värre är att när man ska ta fram en ny produkt ökar underhållet med ca tio man i stället för en, och kunderna (som har fler än en variant) tycker att man har dålig kvalitet eftersom fel som rättats i en variant dyker upp i en annan. Detta temanummer handlar om hur man undviker att hamna i ovanstående situation och hur man, om man redan skulle vara där, tar sig ur den. Härmed önskar jag er en stunds berikande läsning. Anders Mattsson Marknadschef Affärsområde Försvar Elektroniksystem Combitech Systems När man så småningom behöver en nästan likadan produkt så kopierar man den gamla, gör några små förändringar och så vidare I takt med att man gör förändringar av produkterna blir de mindre och mindre lika varandra, inte för att de egentligen skiljer så mycket i funktionalitet utan för att olika personer underhåller dem separat. Nr 1 mars

4 AV ANDERS MAGNUSSON Väx med produktfamilj Hur man behåller kontrollen över produktfamiljen I strävan att öka företagens tillväxt måste många företag nå en större kundgrupp. Ofta leder detta till introducerandet av fler varianter. Det innebär allt som oftast en kraftig kostnadsökning för att hantera det stora antalet produktvarianter. Både utvecklings-, produktions- och underhållskostnad påverkas då en produktvariant i taget hanteras. Den övergripande produktegenskap man strävar efter för att nå lönsamhet är en hög grad av återanvändning mellan olika produktvarianter, dvs man måste sträva efter att uppnå färdig variabilitet i det som återanvänds. Inom vissa områden är affärsmodellerna sådana att kunderna har behov av en stor grad av anpassning till sin specifika miljö, t ex för militära ledningssystem, tåg eller bussar. Här drivs man av anpassningsbarhet av det som återanvänds. Företagsfusioner för besparingar genom samordning Trenden idag är att företag slås ihop i förhoppningen att öka lönsamheten genom samutnyttjande, samtidigt som det ger tillgång till flera varumärken för att nå fler kundgrupper. Att bibehålla det märkesunika spär på utmaningen i produktutvecklingen i samband med återanvändningen. Vanligt är att de olika varumärkena erbjuder samma funktion mot användaren i vilka endast ett fåtal element kommer att forma det märkesunika. I en del fall är det bara estetiska element, såsom utformningen av ett användargränssnitt eller höljet till en mobiltelefon, som varierar. I andra fall skiljer det i erbjudandet i någon extrafunktion. Problembilden ökar dramatiskt när de olika märkena erbjuder likadan funktionalitet mot användaren, men där det märkesunika handlar om egenskaper som säkerhet, tillgänglighet, livslängd, vilka snarare berör helheten än några enstaka element. Ett sådant exempel, hämtat några år bakåt i tiden, är användningsfallet bromsa bilen, något som ju alla bilar sedan 100 år bakåt i Domän Figur 1 En konceptuell modell över plattformsbaserad produktutveckling. Befintliga system Domänexpertis tiden erbjuder. Detta kan dock göras mer eller mindre bra, dvs det är prestandaegenskapen (bromssträckan) som driver utvecklingen och skiljer märkena åt. Sätten att lösa detta på är många, ett är större bromsskivor, ett annat att göra bromsarna låsningsfria (ABS). För några år sedan var det just ABS som kom att bli en valbar kundoption och som ett tag särskiljde olika varumärken och bilmodeller åt. Idag har ABS i stort sett blivit var mans egendom i jakten på marknadsandelar. En bas som kan vidareutvecklas I ett relativt moget produktområde måste man kontinuerligt erbjuda marknaden förbättrade produktegenskaper för att bibehålla marknadsandelen. Inte alls lika ofta identifieras nytt användande. Att snabbt komma ut på marknaden med nya produkter som möter detta kräver att man återanvänder, dvs att man har en bas som man kan vidareutveckla utan att för den skull behöva göra om denna bas vid varje ny produktvariant. Referenskrav Referensarkitektur Plattformskomponenter Prod. specifik Kravanalys Nya krav Prod. specifik Systemkonstr. Prod. specifik Komponentkonstruktion Komponentanpassning. Prod. specifik Komponentrealisering Fokusera på kärnområden vid utvecklingen Väx med en produktfamilj handlar helt enkelt om en ökad grad av modularitet med inbyggd variabilitet och anpassningsbarhet för att kunna öka återanvändningen. Användandet av modulära plattformar kan korta ner tiden till marknad med upp till 50 procent. Genom att låsa nyckelområden vid produktutveckling i plattformskomponenter (moduler) så kan företagen fokusera utvecklingen på de kärn- Domänkravanalys Domänarkitekturanalys Plattformskomponentkonstruktion Plattformskomponentrealisering Plattformskomponentverifiering Prod. specifik Komponentintegration Återmatning Prod. specifik Systemverifiering Tänk produktfamilj Det här kräver att man allt som oftast måste anamma ett helt annat synsätt redan vid produktutvecklingen än att utveckla varje produkt för sig. Det företaget måste göra är att utveckla en produktfamilj där de enskilda produkterna (varianterna) bygger på gemensamma tillgångar en så kallad produktfamiljplattform. En modell av hur plattformsbaserad produktutveckling går till ser vi i figur 1. Man kan tycka att detta borde vara ett välkänt område med en mängd metoder/tekniker tillgängliga, men vi kan nog med fog påstå att det inte är särdeles väl utforskat, varken inom det mekaniska området eller inom programvaruområdet, även om intresset nu ökar. Produktfamiljtänkandet är ett framväxande område som har kommit för att stanna. Plattformsutveckling Plattformstillgångar Produktspecifik utveckling 4 Nr 1 Mars 2004

5 Figur 2 Organisation Referensarkitektur Produktlina (plattform) Produktfamilj Produktvariant Process Metod och Verktyg Arkitekturens roll vid produktutvecklingsrelaterad verksamhetsutveckling. områden som krävs för att produkten skall vara ledande och snabbt uppgraderbar. Att få kontroll på vad som kan variera och var varianser hanteras är därmed av yttersta vikt för att kunna växa med en produktfamilj. Det kräver en tydlighet och synlighet, vilket i sin tur kräver att variabiliteten kan visualiseras på enkelt sätt. Mer om detta kan du läsa om i artikeln Modellera produktfamiljvariabilitet i fordonssystem. Det vi kan se i figur 1 är att de centrala delarna i en produktfamiljplattform är Referenskrav - när det gäller krav inom en viss produktdomän kan vi se att merparten av dessa är samma från gång till annan. Därmed så kan dessa återanvändas från projekt till projekt. Produktlinjearkitektur (referensarkitektur) vilken oftast är en kraftig investering i arbete från de mest erfarna inom företaget för att uppnå egenskaper så som variabilitet, återanvändning, prestanda, tillgänglighet, etc. Många arkitekturstrategier/-koncept har kommit att påverka både organisation (vid produktbaserad organisationsstruktur) och utformningen av arbetsprocess samt valet av verktyg som stödjer detta arbetssätt. Därmed så spelar referensarkitekturen en central roll i verksamhetsutvecklingen (se figur 2). Plattformskomponenter där deras detaljerade (interna) konstruktion, realisering och komponenttester kan återanvändas från produkt till produkt (inklusive all typ av dokumentation kopplade till dessa). Intressant är att detta kan handla om s k abstrakta komponenter (komponent som inte har en specifik realisering kopplat till sig) som varje produktprojekt måste specialisera. Denna specialisering återmatas och så småningom kan detta leda till konkreta komponenter i plattformen med inbyggda möjligheter till varians. Ett stegvist sätt att närma sig en produktplattform behandlas i artikeln Inkrementell utveckling av en produktplattform. Men även projektplaner, budgetar, estimat, verifieringsplaner, testfall, testmiljöer, konfigurationshantering, verktyg, etc kan återanvändas och vara en del av produktflattformen. Notera dock att för varje utvecklad produktvariant så brukar det innebära att det finns produktunika element, även om drömmen är att man bara genom parametrisering av tillgängliga element skall kunna skapa en ny produktvariant. Sedan är det ju så att utvecklingen av produktplattformen och dess delar sällan står helt still. Det innebär att varje element i produktfamiljplattformen kommer att finnas i olika versioner. Konfigurationshantering hänger starkt samman med att få en produktfamiljplattform att fungera men om inte arkitektur och den detaljerade konstruktionen av produktfamiljen är byggd för återanvändning och variabilitet så kommer aldrig konfigurationshanteringen att lösa problemet. Fundamentala tekniker Genom åren så har det utvecklats ett antal fundamentala tekniker som ligger till grund för många av dagens metoder och tekniker, t ex objektorientering och konstruktionsmönster anammar flera av dessa. Då flera av dessa tekniker är fundamentala för en lyckad systemutveckling är det förvånande att se hur få som känner till dem. När det gäller att tänka produktfamilj så ser vi att behovet av att förstå dessa har ökat. Några av de mer centrala är: Modularisering Modularisering avser att hantera en meningsfull nedbrytning av systemet och dess gruppering i delsystem och komponenter. Syftet med detta är att hantera komplexitet genom att introducera väldefinierade gränser mellan dessa. När vi bryter ned ett system i meningsfulla områden så ser vi att dessa inte är fullständigt oberoende av varandra utan de relaterar till varandra på olika sätt. För att förstå detta är det viktigt att visa på ur de förhåller sig till varandra, framför allt om relationen är t ex optionell. Separation of Concern Olika eller orelaterade delar bör separeras från varandra inom systemet. Om en komponent spelar olika roller i olika kontext, så skall dessa roller separeras från varandra inom komponenten, dvs. i dessa sammanhang handlar det om att olikartade ansvarsområden skall separeras från varandra. Coupling and Cohesion Koppling är ett mått på styrkan hos en relation etablerad av kopplingen mellan en modul och en annan. Stark koppling komplicerar systemet eftersom en modul blir svårare att förstå, ändra eller korrigera om den är starkt integrerad med en annan modul medan cohesion handlar om att en modul enbart skall hantera ett problemrelaterat beteende, dvs. hur starkt aktiviteter inom en modul hänger ihop. Separation of Policy & Implementation Innebär att en komponent skall hantera policy eller implementation, inte båda. En policykomponent hanterar omgivningskänsliga beslut och har därmed kunskap om omgivningen, medan en realiseringskomponent enbart hanterar själva utförandet av en algoritm i vilken inga omgivningskänsliga beslut hanteras. Nr 1 mars

6 AV STEFFEN THIEL OCH ANDREAS HEIN, ROBERT BOSCH CORPORATION Modellering och användning av produktlinjevariabilitet i fordonssystem Copyright 2003 IEEE. Publicerad med tillstånd av IEEE. Ursprungligen publicerad på engelska i IEEE Software nr July/August 2002, med namnet Modeling and Using Product Line Variability in Automotive Systems. Fordonssystem omfattar en lång rad funktioner som i grunden förbättrar förarens och passagerarnas komfort, säkerhet och ekonomi. Parkeringsassistans och adaptiv farthållning gör det lättare att köra bilar under olika körförhållanden, vilket minskar förarnas arbetsbörda och ökar komforten. Säkerhetsrelaterade system, såsom automatisk stabilitets- eller krockkuddskontroll, hjälper förarna undvika eller minska effekterna av olyckor. Bränsleekonomisystem minskar utsläppen och ökar bränsleverkningsgraden, och säkerhetssystem skyddar bilarna mot obehörig manipulering. Ett fordonssystem omfattar normalt specialiserade processorer, mjukvara och gränssnitt som låter systemet mäta, påverka och på andra sätt samverka med den yttre miljön. Utvecklarna optimerar dessa system så att de motsvarar de specifika behoven för varje tillämpning. De som utformar fordonssystem måste utöver systemets önskade funktionalitet även ta ställning till flera potentiellt motstridiga egenskaper och begränsningar. Utveckling av ett fordonssystem kan därför inbegripa hundratals eller tusentals varianter som ökar den befintliga systemkomplexiteten. Variabiliteten har tidigare vanligtvis behandlats från fall till fall i de sena utvecklingsfaserna, men utvecklarna behöver nu en kontrollerad och systematisk metod för att kunna hantera det allt större antalet varianter. Produktlinjer erbjuder en sådan systematisk metod, tillsammans med särskild fokusering på variabilitet bland besläktade produkter. Som vi anför här är systematisk planering och kontinuerlig variabilitetskontroll en förutsättning för effektiva produktlinjer. Vi har utvecklat en metod för modellering och användning av variabilitet till stöd för en effektiv framtagning av produktvarianter. Vår metod bygger på erfarenheter från flera industriella fallstudier vid Bosch. Innan vi går in på dem ska vi förklara hur produktlinjeutveckling motsvarar de främsta designutmaningarna på fordonssystemsområdet. Produktlinjer erbjuder en lovande metod för utveckling av fordonssystem eftersom de medger strategisk återanvändning av kärntillgångar. För att uppnå märkbara volymfördelar måste dock variabiliteten beaktas på ett systematiskt sätt under hela utvecklingsprocessen. Produktlinjeutveckling Fordonssystem baseras normalt på tusentals krav, varav några är särskilt viktiga. Många fordonssystem är realtidssystem med stränga tidskrav som stammar från interna reglerloopar. Riktigheten i en viss bearbetning beror därför delvis på dennas tidsprecision. Vidare måste utvecklarna garantera säkerheten och tillförlitligheten hos fordonssystemets mjukvara och inbyggda omborddator, till och med under svåra förhållanden med hög värme eller kyla, vibrationer, stötar, varierande kraftförsörjning, vatten och korrosion. En annan viktig egenskap hos fordonssystem är deras tillgänglighet. Möjligheten att underhålla systemet kan även vara betydelsefull. Äldre mjukvara kanske måste kunna användas tillsammans med nyare hårdvara. Slutligen är intrångsskyddet helt avgörande. Utvecklarna måste kunna garantera att systemmjukvaran inte är lätt att manipulera. Även om flera av dessa utmaningar kräver omfattande forskning och analys har de flesta kunnat lösas med hjälp av tekniska lösningar. Att ta fram sådana lösningar på ett sätt som är både kostnadseffektivt och medger en snabb lansering på marknaden fortsätter att vara en utmaning för både traditionell och plattformsbaserad utveckling. Traditionell utveckling Dagens bilar har flera fordonssystem. Lyxbilar kan till exempel innehålla över 80 elektroniska styrenheter som arbetar fritt från varandra i delvis sammanlänkade system. I dessa system är mjukvaruinnehållet ofta kraftigt anpassat till den underliggande hårdvaran och applikationerna fasta, mycket specifika funktioner (till exempel att justera säten eller hissa upp fönster). Även om företagen tidigare kan ha ansett det vara kostnadseffektivt att utveckla enfunktionella enheter, är detta knappast fallet när vi ser till fordonssystemens samlade funktionalitet i en bil. De oproportionerligt höga hårdvarukostnaderna, tillsammans med närmast orimliga kostnader för utveckling och underhåll av de olika fordonssystemens mjukvara, gör traditionell utveckling av en enhet i taget extremt oattraktiv. Vidare gör den begränsade återanvändbarheten som blir följden av att mjukvaran är kopplad till specifik hårdvara tillsammans med separata inkapslingar, ökad kraftförbrukning och större elektromagnetiska störningar det svårt att uppnå lönsamhet för traditionellt konstruerade fordonssystem. Plattformsbaserad utveckling För att komma till rätta med dessa problem har industrin nyligen börjat integrera fordonsfunktioner på kraftfulla universalplattformar där elektroniska och mekaniska komponenter ersätts med intelligenta mjukvarulösningar. Till exempel använder företagen nu gemensamma plattformar för informationsoch underhållningssystem (inklusive radio, CD-spelare och navigationssystem) samt säkerhetssystem (inklusive parkeringsassistans och kollisionsdetektering). Även om införandet av plattformsbaserad utveckling medger ytterligare funktioner, ökad flexibilitet och användning av gemensam hårdvara har kostnadseffektiviteten och tiden för produktlansering ännu inte beaktats. Följaktligen uppvägs inte de insatser som krävs för att utveckla mer komplex plattformsmjukvara fullt ut av besparingarna på hårdvarusidan. Metoden med produktlinjer Trots de stora volymerna förekommer fordonssystem ändå i otaliga varianter till följd av skillnader i fråga om kundpreferenser, pris 6 Nr 1 Mars 2004

7 och teknik. Därför är strategisk återanvändning oumbärlig för att säkerställa volymfördelar. Vi kan uppnå detta genom att införa en metod med produktlinjer för plattformsbaserad utveckling. En produktlinje för mjukvara utgörs av en uppsättning mjukvaruintensiva produkter med en gemensam, kontrollerad uppsättning funktioner och egenskaper som tillgodoser specifika behov för ett visst marknadssegment. Utvecklingen av produktlinjen löper vidare på ett förutbestämt sätt utgående från en gemensam uppsättning kärntillgångar. Volymfördelar antyder möjligheter till storskalig anpassning, vilket i sin tur kräver ett systematiskt övervägande av variabiliteten under hela produktlinjens utveckling. Paradoxalt nog avfärdas den senare ofta som underordnad. Trots det är, som vi nu ska visa, denna variabilitet avgörande för att uppnå effektiva produktlinjer. Figur 1. Hantering av variabiliteten under hela utvecklingen av kärntillgångar. Figuren visar en representativ uppsättning processer (ljusgråa boxar) och företeelser (röda boxar). F3 Parkeringsassistans F1 Applikation Analys av produktlinje Produktlinjens funktions- och egenskapsmodell Planering av produktlinje Produktlinjens arkitektur Design och implementering av produktlinje producerar används_till producerar används_till producerar mappar_till System för övervakning av en bils periferi F4 Kollisionsdetektering Utveckling av kärntillgångar F5 Front mappar_till F2 Sensorutrustning Komponenter, design/modeller och källkod F6 Bak Modellering av produktlinjevariabilitet Utveckling av produktlinjeprodukter skiljer sig från utveckling av enstaka produkter på så sätt att variabiliteten är en inneboende del av modelleringen. Detta innebär inte att tidigare metoder för mjukvaruutveckling är föråldrade. I stället måste vi både bredda dessa metoder och utveckla nya. Variabiliteten påverkar samtliga aspekter av produktlinjen från krav till kod. Vi behöver helt klart specifika lösningar till stöd för de specifika kundbehov som motiverar variationen. I nuläget hanterar dock utvecklarna ofta variabiliteten som om den är av underordnad betydelse. De introducerar den vanligtvis sent under design- eller implementeringsfasen och uttrycker den ofta genom oräkneliga kompileringsväxlar. Vidare introducerar utvecklarna ofta variationspunkter utgående från heuristik eller expertsystem. Dokumentationen av de variabla krav som motiverar en variationspunkt är ofta underförstådd, vilket gör det svårt att identifiera skälet till variationen. Sådana arbetsmetoder F7 Avståndsindikering F13 Front F14 Bak F8 Styrningsassistans Figur 2. En funktions- och egenskapsmodell till en produktlinje som tillhandahåller periferiövervakning till en bil med hjälp av sensorer som ser föremål i bilens omedelbara omgivning. F anger en funktion eller egenskap. Fyllda bågar anger ELLER-funktioner och tomma bågar anger alternativa funktioner. Fyllda cirklar anger obligatoriska funktioner och tomma cirklar anger valfria funktioner. gör produktanpassningen och särskilt integrationen av nya funktioner och egenskaper komplex och felbenägen. En sen hantering av variabiliteten under utvecklingen gör att företaget förlorar möjligheten att uppnå betydande volymfördelar. Vår metod tar itu med dessa problem genom att systematiskt och kontinuerligt inkludera variabiliteten under produktlinjens hela utveckling. Vi måste införa och förfina variabiliteten i samband med utvecklingen av F9 Nedtill F10 Upptill F11 Nedtill F12 Upptill kärntillgångarna och låta den avspeglas i de producerade företeelserna. Figur 1 visar en representativ uppsättning processer och företeelser. En mer heltäckande överblick finns i litteraturen. Funktions- och egenskapsmodell Funktions- och egenskapsmodellen är ett viktigt resultat av produktlinjens kravanalys. Den inrymmer både produktlinjens funktio- Nr 1 mars

8 Kollisionsdetektering Situationsutvärdering Avståndsindikering Avståndsindikering Smart sensor (mitt front) Smart sensor (vänster bak) Smart sensor (höger bak) Situationsutvärdering F1 F7 F2 F5 F6 Applikation VP1 VP2 VP5 VP6 Indikeringsintervall Övervakningsintervall Sensortyp (b) Styrningsassistans Sensorläge VP3 Prioritetshantering VP4 Komponentgrupper Samverkan (a) Sensorövervakning Mätsamordning Beroende Figur 3. Variabilitet i den logiska arkitekturen (a) och den fysiska arkitekturen (b).variationspunkterna tillgodoser variabiliteten för kraven i figur 2. F anger en funktion eller egenskap och VP en variationspunkt. nella och icke-funktionella egenskaper, såväl som deras gemensamheter och varianser. Den ger även olika intressenter en värdefull överblick över produktlinjen. Till exempel kan kunder använda funktions- och egenskapsmodellen för att skaffa sig en förståelse av produktlinjens funktionalitet, medan systemarkitekter och produktingenjörer kan använda den för att driva utvecklingen av produktvarianter. Figur 2 visar ett förenklat exempel på en produktlinjes funktions- och egenskapsmodell till en bils system för periferiövervakning. Ett periferiövervakningssystem omfattar funktioner för förarens och passagerarnas komfort och säkerhet utgående från sensorer som ser föremål i bilens omedelbara omgivning. Funktions- och egenskapsmodellen ger periferiövervakningssystemets produktlinjefunktioner en trädstruktur som visar utvecklarna vilka varianter de ska ta fram samt vilka begränsningar som gäller för de möjliga kombinationerna. För tydlighets skull har vi utelämnat begränsningarna i figur 2, som därför bara visar trädstrukturen. Applikationsgrenen behandlar periferiövervakningssystemets avsedda funktionalitet. Sensorutrustningsgrenen visar vilka hårdvaruvarianter som behövs för att realisera sensorplattformen som funktionaliteten baseras på. Som framgår av figur 2 omfattar ett periferiövervakningssystem minst en av två applikationer: parkeringsassistans och kollisionsdetektering. Parkeringsassistans består i princip av en bakre avståndsindikering. Vi kan även bygga ut den med främre avståndsindikering och styrningsassistans. Vi kan definiera sensorutrustning till bilens front eller baksida samt använda varianter som antingen sitter nedtill eller upptill för dessa. Produktlinjens arkitektur Arkitekturen är den första designföreteelsen som placerar krav i lösningsrymden. Utvecklarna organiserar vanligtvis arkitekturbeskrivningen i multipla arkitekturvyer. Varje vy representerar slutsystemet ur ett visst perspektiv samtidigt som den avspeglar en eller flera intressenters önskemål. I fallet med produktlinjer måste arkitekturen även omfatta designelementens variabilitet. Den arkitekturrelaterade variabiliteten representerar alternativa designalternativ som inte kunde inkluderas under modellering av arkitekturen. Utvecklare uttrycker ofta denna variabilitet med en uppsättning arkitekturrelaterade variationspunkter som visar (en del av) arkitekturens lösningar för variabla funktioner och egenskaper. En funktions- och egenskapsmodell kräver dock inte någon specifik design, utan antyder snarare vad utvecklarna måste ägna särskild uppmärksamhet åt för att ge arkitekturen struktur till exempel i fråga om konfigurerbarhet. Det är dock inte troligt att konfigurerbarhet är det enda attributet som en utvecklare måste beakta vid framtagning av arkitekturen. I förbindelse med bilar har som tidigare nämnts även prestanda, säkerhet och tillförlitlighet stor betydelse. Den slutliga arkitektu- 8 Nr 1 Mars 2004

9 Produktlinjens funktions- och egenskapsmodell används_till Produktutveckling mappar_till Produktlinjearkitektur används_till beskriver sensorutrustningen som den angivna funktionaliteten kräver. Variabiliteten påverkar även andra arkitekturvyer, inklusive process- och implementeringsvyerna, vilket vi diskuterar i ett annat sammanhang. producerar Produktegenskaper mappar_till ren måste beakta alla funktionella och ickefunktionella krav, inklusive kvalitetsattribut och konstruktionsbegränsningar. Figur 3a och 3b visar variabiliteten i de logiska och fysiska vyerna av periferiövervakningssystemets produktlinjearkitektur. Vi inför variationspunkter på arkitekturnivå för att tillgodose variabiliteten bland kraven i figur 2. Vi karakteriserar varje variationspunkt genom att ange hur och när den är tillämplig. Som de heldragna linjerna mellan dem visar kan variationspunkter vara beroende av varandra för att definiera enhetliga komponentkonfigurationer. Den logiska vyn omfattar fyra variations- används_till Funktions- och egenskapskonfiguration Arkitekturkonfiguration Härledd arkitektur producerar används_till Arkitekturanpassning producerar Produktarkitektur Figur 4. Samverkan mellan funktions-/egenskaps- och arkitekturmodeller vid tillämpning av variabilitet. Ljusgröna boxar representerar processer och mörkgröna företeelser. punkter. Som pilarna visar påverkar variationspunkt 1 en logisk komponent, styrningsassistansen, och två komponentgrupper. Variationspunkterna 2, 3 och 4 påverkar bara individuella logiska komponenter (avståndsindikering, sensorövervakning respektive mätsamordning). Vidare finns det beroenden mellan variationspunkterna 1 och 3, 1 och 4 samt 2 och 5. Variationspunkt 2 parametriserar indikeringsintervallets mjukvara, medan variationspunkterna 5 (övervakningsintervall) och 6 (sensortyp) mappar motsvarande element mot hårdvaruplattformen. Variationspunkterna 5 och 6 är delar av periferiövervakningssystemets fysiska vy och Annat arbetsmaterial Funktions- och egenskapsmodellen samt arkitekturens dokumentation utgör bara en del av arbetsmaterialet som krävs för att utveckla produktlinjer. Funktions- och egenskapsmodellen representerar de olika slutprodukternas särarter, vilka byggs utifrån en gemensam produktlinje (plattform). För att ta fram produktlinjens produkter måste utvecklarna ständigt förfina sina designlösningar för att realisera både gemensamma och variabla funktioner och egenskaper i samband med den detaljerade utvecklingen och implementeringen. Det är inte alla variabla funktioner och egenskaper som nödvändigtvis påverkar arkitekturens övergripande struktur. Utvecklarna kan inkludera en del variabilitet i arkitekturhänseende som först träder fram på en mer detaljerad nivå. Framför allt i fallet med fordonssystem finns det problem (och variationer av dessa) som utvecklarna på ett fullgott sätt kan tillgodose genom komponentdesign eller kodkonstruktion. Exemplen inkluderar algoritmbaserade konverteringar av återkopplingsrelaterade aktiviteter, kryptering av mjukvarans kod för att förhindra obehörig manipulation samt körtidsdata och instruktionskomprimering för optimerad minnesanvändning. I takt med att utvecklarna förfinar arkitekturen i samband med design och implementering ökar vanligtvis antalet variationspunkter eftersom mekanismerna i slutänden måste realiseras genom konstruktioner på en lägre abstraktionsnivå. Trots det måste de konkreta lösningar vi använder för att implementera en variationspunkt följa de konventioner som anges av arkitekturen. För att kontrollera denna process är det avgörande att införa Nr 1 mars

10 F1 Applikation F2 Sensorutrustning Situationsutvärdering Avståndsindikering Smart sensor (vänster bak) Smart sensor (höger bak) F3 Parkeringsassistans F6 Bak VP1 Applikation Prioritetshantering F7 Avståndsindikering F11 Nedtill VP3 Sensorläge VP4 F14 Bak Sensorövervakning Mätsamordning (a) (b) (c) Figur 5. Periferiövervakningssystemets variant för parkeringsassistans, inklusive (a) produktfunktioner, (b) de relaterade variationspunkterna i en del av den logiska vyn, samt (c) en del av den härledda fysiska vyn, som inte innehåller någon variabilitet och därför kan överföras direkt till produktarkitekturen. fullgoda spårbarhetslänkar som visar motivet bakom en variation på kodnivå. Användning av produktlinjevariabilitet Som vi tidigare nämnt existerar inte arbetsmaterial som tas fram i samband med utveckling av produktlinjer isolerat för sig självt. De blir snarare allt mer relaterade till varandra i takt med att utvecklarna förfinar och realiserar kraven steg för steg från analys till kod. Den stegvisa förfiningen inkluderar den variabilitet som först identifierades i funktionsoch egenskapsmodellen och sedan implementerades i de arkitekturrelaterade variationspunkterna. Utvecklarna bör uttryckligen mappa funktioner och egenskaper mot motsvarande arkitekturrelaterade variationspunkter. I princip visar denna mappning hur arkitekturens variabilitetsmekanismer bidrar till att realisera funktions- och egenskapsmodellens variabilitet. I figur 3 visar vi denna mappning med hjälp av funktionsidentifierare kopplade till de arkitekturrelaterade variationspunkterna. Till exempel påverkar de alternativ som är kopplade till applikationsfunktionen (F1) den arkitekturrelaterade variationspunkten 1. Denna punkt hänger samman med motsvarande logiska komponenter i produktlinjens arkitektur. Variationspunkterna 3 och 4 påverkas endast indirekt av funktions- och egenskapsvarianter (genom sin relation till variationspunkt 1). Variationspunkt 6 är beroende av funktions- och egenskapsspecifikationen för såväl den främre (F5) som den bakre (F6) sensorutrustningen. Detta exempel väcker två viktiga frågor: Överensstämmelsen mellan funktioner och egenskaper samt arkitekturrelaterade variationspunkter är sällan 1:1 (F5 och F6 mappar till exempel båda till variationspunkt 6). De arkitekturrelaterade variationspunkterna introducerar inte någon ny variabilitet, utan realiserar snarare funktions- och egenskapsmodellens variabilitet. Variationspunkterna 3 och 4 strider inte mot detta påstående utan stöder bara variationspunkt 1 respektive funktion F1. Spårningen mellan funktioner/egenskaper och arkitektur hjälper inte bara intressenterna att förstå hur utvecklarna har realiserat produktlinjevariabiliteten, utan kan även användas för en effektiv härledning av nya produkter. Vi föreslår därför en utvidgning av konceptet med funktions- och egenskapsmodellering till stöd för utveckling av produktlinjens produkter, med början vid deras funktionsoch egenskapsspecifikationer.grundtanken är att välja mellan olika funktionsalternativ och lösa variabiliteten i enlighet med kundernas behov. Vi kan till exempel specificera en lågt sittande parkeringsassistans som visar avståndet till föremål bak genom att välja funktionerna/egenskaperna F3 och F11 (se figur 2). 10 Nr 1 Mars 2004

11 Sådana val måste stämma överens med relationerna mellan funktionerna. Efter val av funktion/egenskap kan en produktutvecklare använda ett konfigurationsverktyg för att överföra valet till arkitekturen. Figur 4 visar hur funktions-/egenskaps- och arkitekturmodellerna hänger samman. Produktlinjens funktions- och egenskapsmodell fungerar som startpunkt för härledning av en slutprodukt. I produktkonfigurationsprocess använder vi funktions- och egenskapsmodellen för att specificera slutprodukten i fråga om funktioner och egenskaper. I arkitekturkonfigurationsprocessen använder vi sedan slutproduktens specificerade funktioner och egenskaper för att länka till motsvarande variationspunkter i produktlinjens arkitektur genom att utnyttja spårbarheten mellan produktlinjens funktions- och egenskapsmodell och arkitektur. Resultatet är en härledd arkitektur som motsvarar den uppsättning funktioner och egenskaper som en slutprodukt ska erbjuda. Arkitekturen utgör även grunden för möjliga justeringar i processen för arkitekturanpassning, vilken leder fram till den faktiska produktarkitekturen. För att underlätta underhåll av produktarkitekturen bör produktutvecklarna bevara spåren mellan den härledda arkitekturen och motsvarande funktioner och egenskaper. Skälet till detta är att produktutvecklarna i slutänden måste anpassa arkitekturen för att lägga till funktioner och egenskaper som bara är specifika för några få produkter. Beslutet om vad som byggs innanför respektive utanför en produktlinje vilar på affärsmässiga överväganden som sätter gränser för produktlinjens (plattformens) omfattning. I praktiken måste nya funktioner och egenskaper som inte direkt stöds av den nuvarande produktlinjearkitekturen fortfarande inkluderas för att tillgodose alla kundkrav. Mindre anpassningar kan dock godtas så länge en funktion eller egenskap bara kräver små, lokala ändringar av arkitekturen och inte påverkar övergripande kvaliteter som utbyggbarhet, underhållbarhet eller variabilitet negativt. Generellt sett måste ledningen fatta ett uttryckligt beslut om sådana extra funktioner och egenskaper ska inkluderas på produkt- eller produktlinjenivå. Figur 5 visar slutproduktens funktioner och egenskaper, motsvarande variationspunkter i den logiska vyn samt den härledda fysiska arkitekturen. Eftersom vi valde F3 och F11 måste vi även välja andra funktioner och egenskaper. F7 och F14 är till exempel obligatoriska delar i alla applikationer för parkeringsassistans (se exempelvis figur 2). Den härledda logiska vyn utesluter genomgående styrningsassistans och kollisionsdetektering, men innehåller fortfarande variationspunkter som måste inkluderas som en del av produktarkitekturen. Den härledda fysiska vyn innehåller ingen variabilitet sedan variationspunkterna 5 och 6 har lösts upp i enlighet med de valda funktionerna, och vi kan därför använda den som direkt indata till produktarkitekturen. Vi arbetar för närvarande på koncept och tekniker för att bredda och förbättra variabilitetsmodelleringen och hanteringen för industriella tillämpningar. Våra forskningsområden inkluderar representationsfrågor samt riktlinjer för modellering och spårbarhet i olika utvecklingsfaser, samt verktyg som utnyttjar variationspunkter till stöd för effektiv produktframtagning. Utöver detta arbetar vi med att förfina våra systemutvecklingsprocesser för att effektivisera utvecklingen av produktlinjer. Arbetsmaterial framtaget vid utveckling av produktlinjer existerar inte isolerat för sig självt. OM FÖRFATTARNA Steffen Thiel är projektledare för produktlinjeförbättringar på Software Technology Department vid Robert Bosch Corporate Research and Development i Frankfurt, Tyskland. Han var ansvarig på Bosch för det europeiska forskningsprojektet ESAPS kring produktlinjer och leder nu Bosch arbete med det efterföljande projektet, CAFÉ. Innan han började arbeta med produktlinjer utvecklade han intelligenta fordonsinformationssystem vid Bosch. Hans forskningsinriktning omfattar kravoch funktionsanalys, kvalitetsdriven arkitekturdesign, härledda produkter och utveckling. Andreas Hein är medlem av forskarstaben vid Corporate Research and Development for Software Technology vid Robert Bosch Corporate Research and Development i Frankfurt,Tyskland. Han har arbetat i flera europeiska mjukvarubaserade produktlinjeprojekt, inklusive PRAISE, ESAPS och CAFÉ. Utöver produktlinjer är hans forskning inriktad på procedurer för programvaruutveckling samt konfigurationssystem. Han har en examen i datorvetenskap från det Tekniska Universitetet i Darmstadt. Nr 1 mars

12 AV SVEN WENNERSTRÖM AudioDev möter snabb teknikutveckling med flera produktvarianter Sedan cd-skivan lanserades för drygt tjugo år sedan har nya format på optiska media kommit i allt högre takt. Efter cd-r och -rw kom dvd-skivan och dess skrivbara varianter. Runt hörnet väntar flera sorters dvd som bygger på blå laser. För AudioDev, som tillverkar testutrustning, ställer utvecklingstakten nya krav på produktutvecklingen.anders Gustafsson beskriver i en intervju hur AudioDev har börjat arbeta med produktvarianter. AudioDev utvecklar testutrustning för optiska media. Kan du beskriva era kunder? Våra kunder är företag som pressar skivor eller äger rättigheterna till innehållet på skivorna. I fallet med r och rw kan även de som äger varumärken vara kunder. Vi har också några kunder bland bibliotek, arkiv och datorspeltillverkare. Skiljer sig kundgrupperna åt? De kunder som tillverkar r- och rw-skivor har helt andra krav än de som pressar skivor med innehåll, som film och musik. Enstaka r- och rw-skivor har inte något direkt ekonomiskt värde. För slutkunden kostar en sådan skiva bara ett par kronor och då kan kunden acceptera att några av skivorna är defekta. Om man däremot köper en film på dvd för ett par hundra kronor, så kräver man att den ska fungera felfritt. Tillverkare och rättighetsinnehavare är mycket mer noggranna med förinspelade skivor. Hur är AudioDevs produkter uppbyggda? I mitten av testsystemet finns en vanlig pc som tillhandahåller ett användargränssnitt, administrerar testerna, ritar och skriver ut grafer och sparar data i en databas. Till datorn kan kunden koppla upp till åtta stycken rackmonterade testare. I dvd-systemen finns fem-sex olika sorters testare, som i grund och botten bygger på två olika testare. Den ena är egenutvecklad, där vi tagit optiken från en kommersiell Runt hörnet väntar flera sorters dvd som bygger på blå laser. För AudioDev, som tillverkar testutrustning, ställer utvecklingstakten nya krav på produktutvecklingen. spelare och byggt egna servon och avkodare. Den andra är en japansk proffsspelare, som vi förpackar i ett antal olika varianter. I testarna finns också egenutvecklade kort där vi analyserar data. Det blir en hel del varianter med olika testare som kan köra tillsammans, hur gör ni för att testa alla kombinationer? Alla varianterna innebär ett stort antal kombinationsmöjligheter. Att testa alla möjliga kombinationer finns det inte tid till. Vissa kombinationer är naturligtvis vanligare än andra. Normalfallet är att våra kunder har renodlade system, med en enda typ av testare. Hur ser du på framtiden, kommer antalet kombinationer att växa ytterligare? Ja, närmast kommer moduler för nästa generations dvd med blå laser. Den är på specifikationsstadiet och finns i flera olika varianter. Trenden verkar vara att det kommer allt fler nya format samtidigt och att nya format kommer i allt snabbare takt. Det blir allt viktigare för oss att kunna anpassa oss snabbare, därför kan vi inte börja 12 Nr 1 Mars 2004

13 om från början med utvecklingen varje gång. Mellan cd och dvd så gjorde vi om allt, både hård- och mjukvara, det finns det inte längre tid till. Hur mycket är egenutvecklat i systemen? Vi har utvecklat både korten och programvaran själva. På den inbyggda sidan även operativsystemet. Vi har som mål att minska andelen som är egenutvecklat. I nästa generations testare, som är avsedda för blålaserskivor, använder vi Linux istället för vårt egenutvecklade operativsystem. Hur skiljer sig programvaran mellan testarna? Vi har till exempel ett par olika varianter av dvd-testare. Mjukvaran på den inbyggda sidan anpassad med ifdef:ar som talar om vilken testare det är som används. Vi använder alltså samma källkod till var och en av testarna och kompilerar ett antal olika varianter. Pc-programvaran stödjer alltså samtliga moduler? Pc-programmet är alltid detsamma. Till pc:n kan vi koppla alla typer av testare och även bygga blandsystem med flera olika typer i racken. Testarna är anpassade efter ett standardiserat gränssnitt mot pc:n och meddelar programvaran vilken typ det är. Pc-programvaran konfigureras så att säga automatiskt. Så funktionsmässigt skiljer sig inte de olika versionerna av programvaran? Nej, inte nämnvärt. Testarna kan däremot skilja sig något. Vissa kan inte mäta alla parametrar. För r- och rw-skivor kan vi till exempel utrusta testarna med extra kort som mäter parametrar som har med oinspelade skivor att göra. Vilka typer av anpassningar i programvaran kan ni göra för kunderna? Filosofin är att alla funktioner i programvaran är tillgängligt för alla kunder. Däremot kan man göra inställningar av testsystemet på pc-sidan. Programvaran medger olika sätt att betrakta och skriva ut data och också möjlighet att stänga ute vissa parametrar. Parametrar som vi inte är riktigt säkra på kan vi mäta, men sedan välja att gömma i programvaran. Om kunderna vill så kan vi aktivera även dessa parametrar. Har ni även möjlighet att göra större förändringar om kunden kräver det? Ett exempel på det är skivorna till spelkonsollen Xbox. Rättighetsinnehavaren Microsoft ställer krav på speltillverkarna att använda Anders Gustafsson på AudioDev. vår utrustning för att testa skivorna. Där har vi utvecklad speciell funktionalitet för en kund. Skivorna till Xbox är inga vanliga dvdskivor, utan vi var tvungna att anpassa vår testutrustning. Vi lade till kod i programvaran för att möta Microsofts krav. Är det möjligt även för tredje part att lägga till funktioner i systemet? Den möjlighet som finns är genom databasen, som är odbc-kompatibel. Det finns idag företag som gör program för trendanalyser med data från databasen. Hur vet ni vilka parametrar som är intressanta att mäta och vad kunderna förväntar sig av produkterna? Det finns två typer av parametrar. Den ena typen är de parametrar som finns i specifikationer. De mäts och kontrolleras mot förutbestämda gränsvärden. Förutom det mäter vi ospecificerade parametrar. För dem gäller best practice och erfarenhet. Erfarenheten har vi samlat på oss under lång tid och vi håller hela tiden kontakt med våra kunder. På r och rw-sidan är det mer komplicerat. Tillverkarna gör ju bara blanka skivor, medan det är slutresultatet efter att kunden bränt skivan som ska vara bra. För just r och rw tillhandahåller vi en helt separat produkt, som bygger på en kommersiell drive och som mäter färre parametrar. Vi har valt att hålla den produkten helt skild från övriga testare, både internt i utvecklingen och gentemot marknaden. Vi har en separat organisation som arbetar med den kommersiella driven och utveckling av den. De har egen pc-programvara, egna kort och egna inbygga system. Hur kom ni fram till det arbetssättet? Det var svårt att lansera så pass olika produkter under samma varumärke. Vi behövde vara tydligare både internt och externt. Internt var det svårt att hitta rätt standard på produkten och externt förväntade sig kunderna att det nya testsystemet skulle prestera lika bra som de som bygger på proffsspelare. Vilka är fördelarna och nackdelarna med skilda organisationer? Initialt fick den nya produkten och den nya organisationen väldigt mycket fokus, vilket var positivt. Efterhand har vi sett att det finns en hel del områden där vi kan ha nytta av varandra. Det finns vinster att hämta både på den tekniska och marknadsmässiga sidan genom att samordna produkterna mer. Så diskussionen om det är rätt eller inte finns hela tiden. Nr 1 mars

14 AV SVEN WENNERSTRÖM Gemensam hårdvaruplattform för olika produktvarianter Linux, öppna gränssnitt och en aktiv partnerorganisation har gjort att Lundaföretaget Axis Communications har ökat antalet produktvarianter på alla nivåer. Från komponenter till färdiga kundapplikationer. Gemensamt för Axis produkter är att de bildar en brygga mellan någon form av teknisk utrustning och nätverket. Paradgrenen är nätverkskameror som innehåller alla delar som behövs för att kopplas direkt till ett nätverk. På samma sätt fungerar företagets skrivar-, cd- och scannerservrar. Utrustning som annars kopplas direkt till en dator blir tillgänglig på hela nätverket. Hjärta och hjärna i produkterna är ETRAX-chippet som Axis själva utvecklat. I chippet finns för förutom cpu även inbyggt ethernet-stöd och en mikrokontroller med konfigurerbara portar. Portarna, till exempel ide eller usb, används för att koppla in enheten som ska anslutas till nätverket. Flera av Axis produkter delar också en Torbjörn Söderberg arbetar med metodfrågor på Axis Comminications. Linuxbaserad mjukvaruplattform. Utveckling och underhåll av plattformen sköts av ett speciellt team inom Axis, där Torbjörn Söderberg är projektledare och arbetar med metodfrågor: Vår uppgift är att utveckla och underhålla plattformen vilket omfattar kärnan, verktyg och generiska applikationer. Med en Linuxbaserad plattform styrs till stor del arkitekturen av operativsystemets unixartefakter. Men medvetenheten om vilken betydelse mjukvaruplattformen har är annars något som Torbjörn menar kommer underifrån: Inom programvaruintensiv industri är det egentligen rätt självklart att man har en arkitektur, även om man inte alltid diskuterar den explicit. På strategisk nivå är det inte säkert att alla är medvetna om arkitekturens betydelse. Betydelsen visar sig först när något som inte passar i arkitekturen ska utvecklas, en ny produktfamilj eller om man står inför ett teknikskifte. Teknikskiften har drivit Linuxplattformen är resultatet av ett par sådana teknikskiften inom Axis. Den första versionen av ETRAX utvecklades till företagets skrivarserver och på den kördes ett proprietärt operativsystem. Program skrivna i c kördes på en traditionell mikrokärna. När produktlinjen byggdes ut med cd- och lagringsservrar i mitten av 90-talet, ökade kraven på variabilitet: flera filsystem och protokoll skulle stödjas. Från akademiskt håll kom förslaget att införa ett objektorienterat ramverk och att använda sig av patterns, implementerat i c++. Vi hoppade på det här när det blev hett inom akademin. Resultatet blev att vi fick utrustningen att uppträda som en Windows-, Unix- eller Mac OSmaskin på nätverket. Stödet för det hade vi implementerat själva: Netware, smb, http och Appletalk och alla filsystemen. Även om arbetssättet var strategiskt riktigt och teknikskiftet hanterades bra i organisationen, så fanns en inbyggd nackdel i metoden. Att utveckla alla nödvändiga drivrutiner själva tar tid och kostar pengar, i synnerhet när protokoll- och filsystemfloran är vildvuxen. Men allt eftersom Linux och fri programvara mognade, kom nästa förändringsvåg. Med Linuxrevolutionen fick vi plötsligt tillgång till drivrutiner för alla väsentliga enheter. Dessutom fick förmågan att hantera många protokoll minskad betydelse i och med att IP gick segrande ur protokollstriden. Det var plötsligt affärsmässigt bättre att använda Linux. Axis är idag en naturlig del av Linux-communityn. Nya versioner av Linuxkärnan kompileras snabbt till ETRAX och förändringar i ETRAX-versionen av kärnan har portats till andra arkitekturer. Det finns också fri programvara som har sitt ursprung i Axis produkter, till exempel JFFS ett journalförande filsystem för flashminnen och en bluetooth-stack. Övergången till att använda Linux i vissa produktfamiljer anser Torbjörn Söderberg har gått bra, även om det fanns vissa barnsjukdomar i Linux för inbyggda system. Arkitekturen är tvingande, men inte på ett negativt sätt. För oss har övergången till Linux inneburit att vi inte behöver utveckla allt själva längre. Gentemot kunderna innebär det ökad trovärdighet, en viss hipphetsfaktor och större möjligheter att anpassa produkterna. Anpassning av produkterna När de flesta produkter bygger på samma hårdvaruplattform, sker differentieringen av produkterna till stor del i mjukvaran. I Axis byggsystem uttrycks produktskillnader i produkternas respektive konfigurationsfil. I några produkter finns också visst utrymme för att skapa varianter i run-time. Även om plattformen är densamma i många av produkterna så är varianterna väldigt konkreta för oss, eftersom boxarna ser olika ut. På kamerorna kan till exempel optiken skilja sig. Mycket handlar dock om ganska enkel typ av variation, hur många portar som finns eller vilken typ av portar det är. Varianterna av Axis produkter har under senare år ökat i det närmaste explosionsartat, 14 Nr 1 Mars 2004

15 Axis Comminications har ökat antalet produktvarianter som en följd av Linux, öppna gränssnitt och en aktiv partnerorganisation. vilket inte minst ställer krav på produkttesterna. Det finns samordningsvinster att göra i testerna, dels kan vi återanvända testfallen och dels är den manuella testningen modulärt uppbyggd och konfigureras med ett webbgränssnitt. Alla kombinationer måste ändå kontrolleras för att leva upp till våra kvalitetskrav. Givande partnerprogram Även högre upp i kedjan finns utrymme att variera produkterna. Axis har valt att koncentrera sig på produktutvecklingen och lämnar utvecklingen av tillämpningar till tredje part. För kamera- och videoprodukterna finns möjlighet för fristående företag att bli en Application Development Partner, ADP. Det finns idag en bra bit över hundra partnerföretag över hela världen som utvecklar och säljer tillämpningar som bygger på Axis teknik. Mestadels handlar det om Windowsprogram, förklarar Torbjörn Söderberg. Det kan vara övervakningscentraler eller program för bildbehandling. Som systemimplementatörer hanterar våra partners mycket av kontakten med de egentliga slutkunderna. Att Axis istället skulle hantera alla tillämpningarna menar Torbjörn hade varit ohållbart. Partnerprogrammet har fungerat väldigt väl och uppfyller målet att utveckla marknaden för Axis produkter genom nya tillämpningar för produkterna. Alla strategier vi använder för variabilitet är här för att stanna, säger Torbjörn Söderberg och menar att kundens önskemål om differentiering ska mötas på flera olika plan. Allt från kompilatorswitchar till mångfalden bland tredjepartsprodukterna. Nr 1 mars

16 AV KESTER CLEGG, TIM KELLY OCH JOHN MCDERMID Inkrementell utveckling av produktlinjer Copyright Fraunhofer IESE. Publicerad med tillstånd av Fraunhofer IESE. Ursprungligen publicerad 2002 på engelska i IESE-Report nr /E, International Workshop on Product Line Engineering:The Early Steps: Planning, Modeling and Managing med namnet Incremental Product-line Development. Avgörande för en framgångsrik produktlinjestrategi är att det finns något sätt att uppnå en global arkitektur som är gemensam för alla produkter. Övergången till denna arkitektur upplevs ofta som det svåra momentet när strategin ska implementeras. Den metod som presenteras här möjliggör dock inkrementell utveckling av arkitekturen med låg risknivå via en förhandlingsprocess. I princip införs småskaliga produktlinjer som levererar produkter av en viss typ till andra system. Systemets intressenter samlas för att förhandla fram ett gränssnitt för produkten och definiera detta i abstrakta termer. I takt med att dessa småskaliga produktlinjer ökar i antal och till slut omfattar de flesta av systemets delar, börjar deras samlade abstrakta gränssnitt definiera produktlinjens arkitektur. Inledning Införandet av en produktlinje för mjukvara innebär användande av en gemensam arkitektur och en uppsättning komponenter. Att låta ett projekt dela andra projekts arkitektur kan vara svårt, speciellt när ett företag tidigare har hanterat sin mjukvaruutveckling på projektbasis. Samtidigt som företaget rör sig mot en gemensam arkitektur för alla sina produkter kan implementeringsstrategin hämmas av nödvändigheten av att generiska krav definieras som en del av en inledande analys. Det förekommer även en uppfattning att den nya arkitekturen i görligaste mån måste omfatta alla förutsebara variationer av framtida produkter och att detta bara kan uppnås genom en tidsödande och dyr analys av återanvändbarhet och variabilitet. Detta kan vara sant till viss del, men ger intrycket att införandet av en ny produktlinje ställer upp besvärliga hinder i fråga om hur mycket processomläggning som krävs. Denna artikel framför uppfattningen att en produktlinjestrategi kan införas med minimal påverkan av pågående projekt, samtidigt som den lägger en god grund för framtida produktvariation. Den visar en metod med låg risk för framtagning av en produktlinjearkitektur i en objektorienterad (OO) miljö med specifika exempel hämtade från C++. Den visade tekniken uppmuntrar överföring av kunskap mellan projekt och medger att arkitekturen utvecklas med tiden. Denna inkrementella utveckling av produktlinjens arkitektur medför att mätmetoder kan sättas in i ett tidigt skede för att utvärdera strategin innan några större investeringar görs för att lägga om processerna. Tekniken har även fördelen att den är lätt att förstå och tillämpa. Grundprincipen är helt enkelt: isolera och definiera ett gränssnitt till enheter som kan användas i andra system. Principen utgår från att samma grundläggande enheter (i vårt fall C++-klasser) är gemensamma för de aktuella systemen, även om de kan variera stort i fråga om implementeringen. Till exempel kommer ett underhållssystem alltid att behöva något sätt att registrera och rapportera fel. Genom att dra en funktionell gränslinje runt dessa områden kan vi se hur enheterna kan användas i olika system med ett enhetligt gränssnitt. Första steget är att hitta ett abstrakt gränssnitt som alla implementeringarna kan dela. Det abstrakta gränssnittet måste förhandlas fram med de team som arbetar på andra system som kan använda, eller redan använder, en liknande enhet i sina delsystem. Förhandlingsprocessen definierar gränssnittet som ska vara gemensamt för en blandning av gemensamma behov och likheter. Produkterna är de konkreta implementeringarna av en produktlinjearkitekturs variationspunkter. Innan de kan föras upp till denna nivå föreslås de först som variationspunkter i en klassmodell för ett visst projekt. Efter att ha specificerat gränssnitten är områdena för förhandling med övriga projekt lätta att identifiera. De projektöverskridande förhandlingarna kring dessa gemensamma gränssnitt kan förberedas under modelleringssteget och budgeteras som externa kostnader i det nuvarande projektet. I denna artikel används enhet som beteckning på ett slutet element karakteriserat av funktionell nedbrytning. Även om vi huvudsakligen avser C++-klasser, skulle ett sådant funktionellt block lika gärna kunna vara delsystemsblock från Matlab Simulink. Det viktiga är att den funktionella gränslinje som definierar graden av återanvändbarhet i huvudsak är densamma i båda projekten. En fördel med C++ är att abstraktionen är en del av språket och att konformitet med gränssnittet kan genomdrivas av kompilatorn. Relaterade arbeten Tankegångarna i denna artikel bygger på arbeten om produktlinjer av Jan Bosch och artiklar presenterade av David Sharp på Software Technology Conference om möjligheten att använda designmönster i förbindelse med produktlinjer. Det har redan publicerats artiklar kring behovet av produktlinjearkitekturer för en effektiv hantering av produktvariationer och denna artikel bekräftar den betydelse som andra tillskriver införandet av en global produktlinjearkitektur. Genomförandet av en inledande analys för att få en uppfattning om produkters återanvändbarhet och variabilitet har behandlats som en del av en tidigare studie på området. Den teknik som förespråkas här bygger på nyligen genomförda arbeten vid University Technology Centre (UTC) in Systems and Software Engineering här vid Universitetet i York. Problemkontext Den här artikeln använder underhållsdelsystemen till Rolls-Royces motorfamilj för civil luftfart som exempel. Ett underhållsdelsystem är inbäddad mjukvara i en säkerhetskritisk realtidsmiljö. Företaget avser att flytta över utvecklingen av mjukvara för motorstyrsystem till en produktlinjestrategi för att möjliggöra ökad återanvändning av lösningar framtagna för äldre motorer. I allt väsentligt 16 Nr 1 Mars 2004

17 Scheduler MessageFactory FaultFactory hanteras med hjälp av väletablerade mönster med factory-klasser som följer vedertagen OO-standard. Den resulterande modellen av ett något förenklat underhållsdelsystem visas i figur 1. Message Fault CombinatorialRules DispatchRules Figur 1: Enkel underhållsarkitektur skiljer sig dessa underhållsdelsystems funktionalitet inte mycket åt från en motor till en annan, och de borde därför utgöra en god grund för en produktlinje för mjukvara. De nuvarande projekten använder en blandning av modellgenererad C-kod och handskriven C++-kod. Tillgången till OO gör det möjligt för oss att använda en rad befintliga designmönster och ett av dessa, AbstractFactory, är idealiskt för implementering av produktlinjer. Exemplet visar hur mönstret tillämpas för befintliga enheter i en klassmodell av delsystemet. Det ger riktlinjer för hur man säkerställer att en produktlinjestrategi väljs, istället för en strategi som kommer att hämmas av krav från det nuvarande projektet. Definiera enheterna En motors underhållsdelsystem tar emot och agerar när det erhåller information om fel från operativsystemet (OS). Efter kontroll och validering av felet gör delsystemet en minnesdump av nuvarande indata till en icke-flyktig minnesarea och genererar ett meddelande som i tillämpliga fall sänds till Snapshot SuppressionRules flygplanets huvuddator. Delsystemets huvudsakliga bearbetning ligger i användning av kombinatorisk logik för att validera felet i relation till andra fel, klareringsbarhet (tillåten tid innan ett fel förklaras giltigt) samt undertryckningsregler som avgör om ett meddelande slutligen kommer att nå cockpit eller inte. Även om underhållsdelsystemet är mycket komplext, kan dess funktionalitet beskrivas med relativt få enheter. Enligt vedertagna OO-principer är det bättre att göra objekt så lättviktiga som möjligt, dvs. att ge dem minimal funktionalitet, för att underlätta framtida underhåll. Detta kan dock leda till en mångfald av klasser i designen, vilket kan påverka projekt som försöker använda gemensamma gränssnitt. Ju fler gränssnitt, desto restriktivare blir den övergripande designen och detta är ett särskilt problem för produktlinjearkitekturer. Mot bakgrund av befintliga specifikationer för integrerad testutrustning (BITE) var fel och meddelanden de två uppenbara kandidaterna för att koppla verkliga objekt till klasser. Objekt skapade från dessa klasser kan Mönstret AbstractFactory Mönstret AbstractFactory har tagits fram för att möjliggöra olika implementeringar av samma funktionella krav inom en gemensam arkitektur. Detta uppmuntrade huvudsakligen en utveckling mot abstrakta gränssnitt, snarare än implementeringsspecifika rutiner som uppvisade likartad funktionalitet. Mönstret medger framtagning av valfritt antal produkter. Vilken produkt som tas fram beror på vilken konkret fabrik som instantiaterats tidigare av klienten. Vid användning av abstrakta basklasser med rent virtuella funktioner kan samma kod användas för att ta fram olika typer av produkter. Klienten anropar helt enkelt gränssnittet som hör till AbstractFactory. Den behöver inte bry sig om vilken konkret fabrik som de facto kommer att instantiatera sin egen version av produkten. Användning av mönstret AbstractFactory Mönstret AbstractFactory kan helt klart hitta en applikation i en produktlinjestrategi för underhållsdelsystemet. Två saker krävs för detta: Ett åtagande om att använda en enda, gemensam arkitektur för framtida underhållsdelsystem. En övertygelse om att samma grundläggande enheter i ett underhållsdelsystem kommer fortsätta att förekomma i framtida designer. Den sista punkten är inte lika viktig som den första, eftersom enheter som vi kommer att se kan överföras gradvis till produktlinjer. Utan den första punkten är dock en produktlinje inte möjlig. Utan den andra punkten finns det inget incitament för att skapa en produktlinje. Nr 1 mars

18 EngineAFaultFactory createfault(int FaultID) getfault(int FaultID) getconfirmedfault(intfaultids) ReceiveSignal(Int SigID) EngineAFault lsconfirmed Confirmed() Update FaultFactory <<virtual>> createfault() <<virtual>> getfault() <<virtual>> getconfirmedfault() ReceiveSignal() EngineBFaultFactory createfault() getfault() getconfirmedfault() ReceiveSignal() EngineBFault lsconfirmed Confirmed() Update EngineCFaultFactory createfault(int FaultID) getfault(int FaultID) getconfirmedfault(intfaultids) ReceiveSignal(Int SigID) EngineCFault lsconfirmed Confirmed(void) Update(void) Fault IsConfirmed <<virtual>> Update() <<virtual>> Confirmed() klassen AbstractFactory (dvs. de produkter som denna produktlinje kan producera) definierade som rent virtuella funktioner. Dessa abstrakta gränssnitt måste förhandlas fram med andra projektteam som kan använda produktlinjen för att ta fram sina respektive enheter. Förhandlingsprocessen behandlas mer ingående i avsnittet Förhandling om de abstrakta gränssnitten. I takt med att antalet produkter växer och fler motorvarianter inkluderas, ökar även modellens komplexitet (och rigiditet). Men ju fler produkter som är definierade för produktlinjen, desto större återanvändning uppnås. Några av fördelarna inkluderar: Ökad robusthet för arkitekturen i takt med att den mognar och omfattar allt fler motorer. Ökad medvetenhet om återanvändbarhet på kravsidan i takt med att kunskaperna sprids bland utvecklarna. Figur 2: FaultFactory och felklasser som visar implementeringar för andra motorer. Konformitet med produktlinjens gränssnitt innebär att flera designöverväganden redan är godkända. Vårt angreppssätt har helt enkelt varit att betrakta var och en av de grundläggande enheterna i klassmodellerna som kandidatprodukter eller produktfabriker i ett underhållsdelsystems produktlinje. I allt väsentligt ger användning av principen definiera och isolera alla variationspunkter för var och en av enheterna i modellen samma resultat. Mönstret AbstractFactory erbjuder bara ett accepterat ramverk för kompilering av olika konkreta implementeringar utgående från generisk kod. Val av lämpliga enheter Om vi utgår från att nästa underhållsdelsystem kommer att vara praktiskt taget oförändrat jämfört med figur 1, förutom att det är specifikt för motorn i just sin implementering, kan vi anta att samma enheter kommer att vara möjliga att återanvända. En tilltalande aspekt av mönstret AbstractFactory är att de kan appliceras på en enstaka enhet i en delsystemsdesign. Enheten kan utgöra en del av en miniproduktlinje, dvs. en produktlinje som producerar en del av ett större delsystem för en produkt. I takt med att designen mognar definierar de småskaliga produktlinjernas abstrakta gränssnitt gradvis den övergripande produktlinjearkitekturen. Genom att hålla dessa små och abstrahera en enhet i taget kan arkitekturen hållas flexibel i inledningsskedet. De transparenta klasserna i figur 2 är abstrakta basklasser med egenskaperna från Specifikation av abstrakta gränssnitt Mycket av framgångarna med produktlinjeimplementeringen beror på förmågan att förutse variationspunkter. Förmågan att förutse sannolika variationspunkter har alltid varit en svår designfråga och design för möjliga förändringar har varit den drivande kraften bakom införandet av OO-teknik. OO-teknik har dock tenderat att fokusera på att uppnå flexibilitet och återanvändning på en lokal, låg designnivå. Produktlinjestrategin kan helt enkelt ses som ett sätt att producera olika, men besläktade produkter. Flexibilitet och återanvändning övervägs i och med det på mycket högre nivåer än traditionellt. Tidigare produktlinjestudier har dock betonat behovet av en detaljerad analys av återanvändbarhet och variabilitet för potentiella produkter. Det kan bli dyrt och tidskrävande att genomföra en sådan studie. Behovet av en 18 Nr 1 Mars 2004

19 inkrementell produktlinjestrategi kommer från företag som inte kan avdela resurser till en fullskalig, inledande analys av sina produktfamiljer. När resurser saknas erbjuder det inkrementella tillvägagångssättet ett relativt billigt alternativ med låg risk för att implementera en produktlinje utgående från ett befintligt projekts baslinje. Vårt synsätt likställer produkter med variationspunkter i produktlinjearkitekturen. När nya projekt sätts igång ligger fokus därför inledningsvis på att bryta ned delsystemet i sina grundkomponenter. Så snart enheterna har definierats grovt har varje enhet potential att bli del av den miniproduktlinje som levererar varianter av enheten till de framtida motorernas underhållsdelsystem. Det är det nya projektets ansvar att besluta om en viss enhet har en plats i framtida system. Om ingenjörerna anser det kan de ta upp det med en produktlinjesamordnare (vars roll beskrivs längre fram) som kan ta upp förslaget med andra projekt. Detta synsätt innebär att produktlinjer kan ses som småskaliga och lättviktiga (i processhänseende) och införas när det passar för det aktuella projektet. Det är viktigt att tidsgränser och pågående arbete för det nya projektet inte störs av detta genom att behöva ta stöten för den omorganisering som krävs för att införa produktlinjen. Nästa nya motors underhållsdelsystem kanske bara kan dela underhållsproduktlinjens meddelandehantering eller felhantering om resten av det generiska delsystemet är för annorlunda för att kunna anpassas. Det finns inget krav att en ny motor inkluderas enligt principen allt eller inget. Inkluderandet kan vara partiellt, men fördelarna med förbättrade processer och en projektöverskridande förståelse för delområdet som sådant är fortfarande värdefulla. Specifikation av en ny produkt Så snart ett delsystems grundläggande enheter har definierats bör en tanke skänkas åt hur dessa enheter kan levereras som produkter från en produktlinje. Med hjälp av mönstret AbstractFactory definierar den abstrakta gränssnittsspecifikationen produktens gränssnitt i form av rent virtuella funktioner som en klient kan anropa. Produkten själv bör ha ett abstrakt gränssnitt som låter den klassificeras som en typ så att klienten kan instantiera den utan att behöva bry sig om dess specifika art. Vi rekommenderar inte att varje detalj i en befintlig och implementerad specifikation tas upp till förhandling för en diskussion kring dess abstrakta specifikation i relation till andra projekt. En produktlinje måste kunna omfatta variabiliteten hos de produkter den levererar och en överdrivet detaljerad gränssnittsspecifikation skulle förhindra detta. Följande steg rekommenderas i processen: 1. Ett kort förslag som visar att enhetens funktionalitet kan vara gemensam för andra delsystem. 2. En kort diskussion kring enhetens funktionalitet inom ett delsystem. 3. Ett förslag att enheten kan levereras till framtida delsystem som en produkt via en produktlinje. 4. En ömsesidig projektbegäran för ett möte för att diskutera produktens gemensamma abstrakta gränssnitt. Förslag som detta, som genomförs under ett pågående projekt, kräver att en budget (och tid) avsätts för arbete med produktlinjen. Underhållsteamen i alla projekt bör boka sin tid mot samma kostnadsställe för detta arbete och medlemmarna i olika team bör rapportera till chefsarkitekten eller produktlinjesamordnaren när de lägger fram förslag relaterade till produktlinjen. Det är viktigt att inget projekt bär hela bördan av att definiera produktlinjen och specifikationen av de abstrakta gränssnitten. Att låta ett visst projekt göra detta när övriga projektrepresentanter är frånvarande resulterar troligen i ett oflexibelt gränssnitt till följd av den sannolika partiskheten för just det projektet. Förhandling om de abstrakta gränssnitten Så snart ett möte har beslutats för den föreslagna produkten och produktlinjen bör utvecklingsteam med relevanta erfarenheter från området delta på mötet för att diskutera vilken grad av variabilitet som produkterna kan tänkas ha. Även om dessa team arbetar med mogna delsystem snarare än nya implementeringar, har de sannolikt värdefulla erfarenheter relaterade till tidigare kravförändringar. De kan vidare ha förslag på svagheter i nuvarande designer eller implementeringar som har orsakat underhållsrelaterade svårigheter och dessa synpunkter bör tas upp på mötet för att hjälpa till att definiera ett abstrakt gränssnitt som alla kan enas kring. En checklista för ett sådant möte bör säkerställa att: enheten kan utgöra en del i framtida delsystem det abstrakta gränssnittet är godtagbart för alla intressenter produktens abstrakta gränssnitt inte är begränsande i fråga om de förväntade konkreta implementeringarna det abstrakta gränssnittet kan spåras tillbaka till generiska krav för alla berörda projekt. Beroende på vilken grad av återanvändbarhet som avtalas mellan projektteamen kan det abstrakta gränssnittet vara mycket enkelt (maximal implementeringsflexibilitet) eller väldefinierat (restriktiv implementering, men med bättre återanvändbarhet). Dessa behov står i konflikt till varandra och vissa projekt kan bli missnöjda över utsikten att behöva använda ett snävare definierat abstrakt gränssnitt. I detta fall, och kanske för att produktlinjen är relativt omogen, kan det vara säkrast att begränsa gränssnittsspecifikationen till ett Nr 1 mars

20 rent minimum för underlätta förhandlingarna. I takt med att produktlinjen och förhandlingsprocessen växer fram mellan teamen går det sannolikt att hitta mer återanvändbarhet att enas kring och denna kan läggas till i de befintliga gränssnitten. Introduktion av tekniken i ett befintligt projekt En av de främsta fördelarna med den teknik som presenteras i denna artikel är möjligheten att applicera mönstret på en enhet i taget. Det medger övergång med låg risk till en produktlinjestrategi och gör det möjligt att fördela kostnaderna och arbetet med att utveckla produktlinjen mellan projekten. Det är lättare att underhålla en serie miniproduktlinjer om processerna för detta byggs upp stegvis och att människor lär sig av sina misstag och förbättrar processen fortlöpande. Att börja med en enda enhet gör det även lättare att införa mätmetoder på ett tidigare stadium så att återanvändningen kan följas upp och fördelarna bedömas. Det bör dock noteras att alltför ingående analys av insamlad information innan produktlinjen är mogen (t.ex. när ett antal produkter är tillgängliga) kan ge missvisande data. Den främsta fördelen med att få mätmetoderna på plats tidigt är att en process kan införas och överväganden göras över vad som exakt ska mätas. När detta är på plats kan data samlas in med större tillförsikt om nästa projekt använder samma gränssnitt och arkitektur. Stegen kan sammanfattas enligt följande: En produktlinjesamordnare utses detta kan till exempel vara chefsarkitekten. Utvecklingsteamet väljer en enstaka enhet som kandidatprodukt för framtida delsystem. Teamet går igenom specifikationsprocessen som skisserades i föregående avsnitt. Produktlinjesamordnaren arbetar med teamet och planerar in möten med utvecklare från andra projekt så att processen att förhandla fram det abstrakta gränssnittet kan börja. När det abstrakta gränssnittet har beslutats bör det publiceras och alla projekt informeras. Tankegångarna bakom det föreslagna abstrakta gränssnittet måste dokumenteras entydigt. Generiska krav bör fastställas som hänvisar till produktlinjestrukturen så att nuvarande och framtida projekt kan spåra återanvändningsavsikten som specificeras av det abstrakta gränssnittet. Arbetet på den konkreta produktimplementeringen för det nuvarande projektet kan sedan börja. Arbetet kostnadsförs på och genomförs av projektteamet som kom med det första förslaget. I samband med denna process är det troligt att det nuvarande projektteamet har mest att säga till om i fråga om det abstrakta gränssnittets specifikation, eftersom deras projekt har störst behov av att bli klart i tid. Det åligger produktlinjesamordnaren och övriga team att se till att förslagen från det nuvarande projektteamet inte resulterar i ett gränssnitt som riskerar att vara begränsande så vitt de kan bedöma. De bör föra fram sina egna projektkrav i förhandlingarna som om de var relevanta nu, eller åtminstone använda sina kunskaper om ändringskrav för att visa på den mest sannolika variationen som kan inträffa från en implementering till en annan. Det finns flera aspekter av produktlinjer som förblir obestämda, men genom att prova ut processen på en eller två enheter kan risken minimeras för att stora investeringar görs i en process som inte ger några verkliga fördelar längre fram. Slutsatser Denna artikel har visat hur en produktlinje kan utvecklas i en objektorienterad C++miljö. Tekniken innebär låg risk och låga startkostnader. Grundprincipen att isolera och definiera alla variationspunkter är enkel och förutsatt att en produktlinjesamordnare har utsetts blir det följande förhandlingssteget kring det abstrakta gränssnittet okomplicerat. Processen har följande fördelar: Övergång med låg risk och minimal påverkan till en produktlinjestrategi. Projektöverskridande förhandlingar kring gemensamma gränssnitt är lätta att identifiera, planera och budgetera. Överföring av kunskap mellan projekten i takt med att produktlinjeprocessen mognar. Inkrementell definiering av arkitekturen medger tidigt införande av mätmetoder för pilotprojekt. Igångsättnings-, design- och utvecklingskostnaderna för nya produkter minskar. Det är viktigt att utvecklarna förstår att de enheter de designar skulle kunna vara produkter i en produktlinje som kan vara av praktisk nytta för andra utvecklingsteam. De bör diskutera potentiella produkter med produktlinjesamordnaren eller chefsarkitekten, som sedan tar ansvaret för att hantera specifikationen och förhandlingarna kring gränssnitten, medan utvecklarna kan fortsätta sitt lokala arbete med det nuvarande projektet. Detta verkar vara ett sätt att utveckla produktlinjer inom en organisation utan onödiga störningar för pågående projekt. Projektens igångsättningstider bör också förbättras, eftersom mycket av infrastrukturen för en enhet bör ha diskuterats och kommit på plats som en del av specifikationen av det abstrakta gränssnittet. Problem I takt med att processen och produktlinjen mognar blir specifikationen av det abstrakta 20 Nr 1 Mars 2004