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

Storlek: px
Starta visningen från sidan:

Download "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 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 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

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell Informationsstruktur 2015:1 Bilaga 7: Arkitektur och metodbeskrivning Innehåll Nationell informationsstruktur arkitektur och metod... 3 Standarder inom informatik... 3 NI relaterat till ISO 42010...

Läs mer

Bonus Rapport Kommersiell Design KTH

Bonus Rapport Kommersiell Design KTH Bonus Rapport Kommersiell Design KTH Johan Holmström & Lars Åkesson Introduktion Denna rapport beskriver projektet och delmomentet Kommersiell Design i kursen Interaktionsdesign 2 på KTH i Stockholm. Detta

Läs mer

30 år av erfarenhet och branschexperts

30 år av erfarenhet och branschexperts 30 år av erfarenhet och branschexperts Integrerad Säkerhet Integrerad Säkerhet Varför överordnat system Användarvänlighet Kvalitet Trygghet Kostnadseffektivitet Varför ett överordnat system? Med stora

Läs mer

Collector en Android-app för att samla saker. Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport

Collector en Android-app för att samla saker. Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport Collector en Android-app för att samla saker Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport Abstrakt Jag har gjort en Android-app för att samla saker, Collector. Med den kan man upprätta att göra-listor

Läs mer

AvI-index. Ett instrument för att mäta IT-systems användbarhet

AvI-index. Ett instrument för att mäta IT-systems användbarhet ANDERS GUNÉR AvI-index Ett instrument för att mäta IT-systems användbarhet Iordanis Kavathatzopoulos Uppsala universitet ISBN 978-91-976643-5-6 Copyright 2008 Iordanis Kavathatzopoulos. Uppsala universitet,

Läs mer

Agil testning i SCRUM

Agil testning i SCRUM Agil testning i SCRUM Petter Salomonsson Petter.salomonsson@addq.se Tel: 0708-398435 Kort presentation AddQ Consulting AB tydlig fokus på test och kvalitetssäkringstjänster erbjuder mycket erfarna konsulter

Läs mer

Processbeskrivning Systemutveckling

Processbeskrivning Systemutveckling ProcIT-P-015 Processbeskrivning Systemutveckling Lednings- och kvalitetssystem Fastställd av Sven Arvidson 2011-09-12 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Systemutvecklingsprocessen

Läs mer

WHITE PAPER. Open End TM Funktionell översikt

WHITE PAPER. Open End TM Funktionell översikt Open End TM Funktionell översikt Open End tillför verksamhetsprocesser nya möjligheter genom att kombinera avancerad teknik för automatiserad informationshantering i realtid med intuition och hög användbarhet.

Läs mer

Metoder och verktyg för funktionssäkerhet

Metoder och verktyg för funktionssäkerhet Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och

Läs mer

Engineering Bases viktigaste egenskaper

Engineering Bases viktigaste egenskaper Engineering Bases viktigaste egenskaper Med Engineering Base intåg på den Svenska marknaden är det många företag som inom de närmaste åren kommer att se över strategin kring sitt CAD system och utvecklingen

Läs mer

Rätt information till rätt person vid rätt tillfälle

Rätt information till rätt person vid rätt tillfälle Rätt information till rätt person vid rätt tillfälle System för samverkan, effektivitet och konkurrenskraft Du håller säkert med om att ditt företags kanske mest värdefulla tillgång består av all den information

Läs mer

Priskamp. En prisjämförelsesite Björn Larsson 130609

Priskamp. En prisjämförelsesite Björn Larsson 130609 Priskamp En prisjämförelsesite Björn Larsson 130609 Abstrakt Detta är en post-mortem slutrapport om mitt projekt "Priskamp" inom ramen för kursen Individuellt Mjukvaruutvecklingsprojekt VT 2013. Projektets

Läs mer

Objektorientering. Grunderna i OO

Objektorientering. Grunderna i OO Objektorientering Grunderna i OO 1 Systemutveckling Tre systemnivåer: Verksamhet Informationssystem Datasystem Huvuduppgifterna i ett systemutvecklingsarbete: Verksamhetsanalys Informationsbehovsanalys

Läs mer

TMP Consulting - tjänster för företag

TMP Consulting - tjänster för företag TMP Consulting - tjänster för företag Adress: http://tmpc.se Kontakta: info@tmpc.se TMP Consulting är ett bolag som utvecklar tekniska lösningar och arbetar med effektivisering och problemslösning i organisationer.

Läs mer

Nokia Lifeblog 2.5 Nokia N76-1

Nokia Lifeblog 2.5 Nokia N76-1 Nokia Lifeblog 2.5 Nokia N76-1 2007 Nokia. Alla rättigheter förbehållna. Nokia, Nokia Connecting People, Nseries och N76 är registrerade varumärken som tillhör Nokia Corporation. Andra produkt- och företagsnamn

Läs mer

ASCOM IP-DECT TRÅDLÖS IP-TELEFONI MED BEPRÖVAD TEKNOLOGI

ASCOM IP-DECT TRÅDLÖS IP-TELEFONI MED BEPRÖVAD TEKNOLOGI ASCOM IP-DECT TRÅDLÖS IP-TELEFONI MED BEPRÖVAD TEKNOLOGI 2 ASCOM IP-DECT Ascom är ledande inom trådlös telefoni för professionella användare. Våra lösningar är kända för sin flexibilitet, tillförlitlighet

Läs mer

Utforma säkerhetsprocesser

Utforma säkerhetsprocesser Utforma säkerhetsprocesser www.informationssäkerhet.se 2 Upphovsrätt Tillåtelse ges att kopiera, distribuera, överföra samt skapa egna bearbetningar av detta dokument, även för kommersiellt bruk. Upphovsmannen

Läs mer

Att använda DVD-RAM-skivor

Att använda DVD-RAM-skivor Denna bruksanvisning innehåller ett minimum av information för att använda DVD-RAM-skivor tillsammans med drivenheten DVD MULTI under Windows 98/Me/2000. Windows, Windows NT och MS-DOS är registrerade

Läs mer

Modularitet VAD och HUR? Håkan Seipel FMV Tekn Dir 19:e maj 2009

Modularitet VAD och HUR? Håkan Seipel FMV Tekn Dir 19:e maj 2009 Modularitet VAD och HUR? Håkan Seipel FMV Tekn Dir 19:e maj 2009 1 Tre typer av modularitet Olika interaktion med Tre system typer av modularitet Modulärt nyttjande Modulär produktion Modulär design 2

Läs mer

2007 Nokia. Alla rättigheter förbehållna. Nokia, Nokia Connecting People, Nseries och N77 är varukännetecken eller registrerade varumärken som

2007 Nokia. Alla rättigheter förbehållna. Nokia, Nokia Connecting People, Nseries och N77 är varukännetecken eller registrerade varumärken som Nokia Lifeblog 2.5 2007 Nokia. Alla rättigheter förbehållna. Nokia, Nokia Connecting People, Nseries och N77 är varukännetecken eller registrerade varumärken som tillhör Nokia Corporation. Andra produkt-

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Molntjänster -- vad är molnet?

Molntjänster -- vad är molnet? En e-bok från Visma Spcs Molntjänster -- vad är molnet? Vad du bör tänka på för att göra rätt val till ditt företag Molntjänster -- vad är molnet? En guide till att förstå molntjänster Innehåll Hänger

Läs mer

Övergripande riktlinjer för IS/IT-verksamheten

Övergripande riktlinjer för IS/IT-verksamheten 1(7) 2004-03-19 Handläggare, titel, telefon Roger Eriksson, Teknisk IT-strateg, 011-151391 Peter Andersson, IT-strateg, 011 15 11 39 Övergripande riktlinjer för IS/IT-verksamheten Inledning De i Program

Läs mer

Insamlingsverktyg - teknisk beskrivning av metadataformuläret

Insamlingsverktyg - teknisk beskrivning av metadataformuläret Digitala leveranser Insamlingsverktyg - teknisk beskrivning av metadataformuläret Innehåll: Allmänt Layout och uppbyggnad Hur man använder programmet Starta Fylla i metadata Skapa metadatafiler och leverera

Läs mer

Programmering. Hur, var, när och varför. 22 November. Lars Ohlén Tieto lars.ohlen@tieto.com

Programmering. Hur, var, när och varför. 22 November. Lars Ohlén Tieto lars.ohlen@tieto.com Programmering Hur, var, när och varför 22 November Lars Ohlén Tieto lars.ohlen@tieto.com Agenda Om mig Programmering Vad är? Varför kunna? Hur använda kunskapen? Framtiden Sammanfattning Q+A 2 Om mig Arbetat

Läs mer

Vad är. Domändriven design?

Vad är. Domändriven design? Vad är Domändriven design? 1 Domändriven design är utvecklare och domänexperter som arbetar tillsammans för att skapa mjukvara som är både begriplig och möjlig att underhålla. ett sätt att fånga och sprida

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

Exempel på verklig projektplan

Exempel på verklig projektplan Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av

Läs mer

Vad är molnet?... 2. Vad är NAV i molnet?... 3. Vem passar NAV i molnet för?... 4. Fördelar med NAV i molnet... 5. Kom igång snabbt...

Vad är molnet?... 2. Vad är NAV i molnet?... 3. Vem passar NAV i molnet för?... 4. Fördelar med NAV i molnet... 5. Kom igång snabbt... Produktblad för NAV i molnet Innehåll Vad är molnet?... 2 Vad är NAV i molnet?... 3 Vem passar NAV i molnet för?... 4 Fördelar med NAV i molnet... 5 Kom igång snabbt... 5 Bli kostnadseffektiv... 5 Enkelt

Läs mer

Uppdatering av programvaror

Uppdatering av programvaror Uppdatering av programvaror Användarhandbok Copyright 2007 Hewlett-Packard Development Company, L.P. Windows är ett USA-registrerat varumärke som tillhör Microsoft Corporation. Informationen häri kan ändras

Läs mer

Process- och metodreflektion Grupp 5

Process- och metodreflektion Grupp 5 Process- och metodreflektion Grupp 5 IDM Grupp 5 Anders Fougstedt, Anders Green, Lay Truong, Anna Sjödin, Tobias Kask Val av metoder Det första steget i vår designprocess var att bestämma vilka metoder

Läs mer

Installera SoS2000. Kapitel 2 Installation Innehåll

Installera SoS2000. Kapitel 2 Installation Innehåll Kapitel 2 Installation Innehåll INSTALLATION MDAC och ODBC...2 Installera SoS2000 i arbetsplatsen...2 SoS2000 serverprogramvara...2 SoS2000 och övriga Office program...3 Avinstallera SoS2000...3 Brandväggar...3

Läs mer

MIC Series 550 Tålig pan-tilt-zoom-kamera för utomhusbruk

MIC Series 550 Tålig pan-tilt-zoom-kamera för utomhusbruk MIC Series 550 Tålig pan-tilt-zoom-kamera för utomhusbruk 2 MIC Series 550 Sätter standarden inom övervakning Tilltalande, kompakt design för diskret integrering i övervakningsmiljöer Tålig, vandalsäker

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

Bosch-batterier: Optimal startkraft till alla bilar

Bosch-batterier: Optimal startkraft till alla bilar Bosch-batterier: Optimal startkraft till alla bilar Rätt Bosch-batteri till alla bilar S5: Energikällan till bilar i högre prisklasser S4: Massor av energi och kraftig start till alla bilklasser S3: Den

Läs mer

Elements, säkerhetskopiering och dina bilder

Elements, säkerhetskopiering och dina bilder Elements, säkerhetskopiering och dina bilder Mattias Karlsson Sjöberg, december 2011. Moderskeppet.se Lär dig tänka rätt och använda rätt verktyg för att säkerhetskopiering, datorbyte och hårdiskbyte.

Läs mer

En CAD-ansvarigs syn på integrering mot CAD.

En CAD-ansvarigs syn på integrering mot CAD. En CAD-ansvarigs syn på integrering mot CAD. Kraven på att minska ledtiderna ökar. Hur kan man med de verktyg som finns på marknaden organisera det hela så att det förenklar konstruktörens arbete och hela

Läs mer

Vilket moln passar dig bäst?

Vilket moln passar dig bäst? Vilket moln passar dig bäst? Idag diskuteras ofta huruvida man ska kliva in i molnets underbara värld eller inte, men sällan om skillnaderna mellan olika moln och vilka tillämpningar som är lämpliga att

Läs mer

Utdrag från kapitel 1

Utdrag från kapitel 1 Utdrag från kapitel 1 1.1 Varför en bok om produktionsutveckling? Finns det inte böcker om produktion så att det räcker och blir över redan? Svaret på den frågan är både ja och nej! Det finns många bra

Läs mer

Säkerställ er tillgänglighet Kommunikationsrapporteringsverktyg

Säkerställ er tillgänglighet Kommunikationsrapporteringsverktyg Säkerställ er tillgänglighet Kommunikationsrapporteringsverktyg Vad är Meridix Studio? Meridix Studio är ett verktyg som låter er analysera och följa upp er kommunikation via ett enkelt men kraftfullt

Läs mer

För smartare belysning

För smartare belysning För smartare belysning CityTouch LightPoint Lighting Asset Management. CityTouch LightPoint / Asset Management 3 Välkommen till framtidens smarta belysning Professionell hantering av offentlig belysning

Läs mer

LEGA ONLINE. Bli lönsammare med Lega Online. www.legaonline.se. - Sveriges största internetbaserade bokningssystem.

LEGA ONLINE. Bli lönsammare med Lega Online. www.legaonline.se. - Sveriges största internetbaserade bokningssystem. LEGA ONLINE - Sveriges största internetbaserade bokningssystem Bli lönsammare med Lega Online Tänk om alla dina bokningar, kunder och artiklar fanns samlade i ett system, med fullständig statistik och

Läs mer

ASSA passersystem. ARX, RX och Smartair. ASSA ABLOY, the global leader in door opening solutions.

ASSA passersystem. ARX, RX och Smartair. ASSA ABLOY, the global leader in door opening solutions. ASSA passersystem ARX, RX och Smartair ASSA ABLOY, the global leader in door opening solutions. ASSA passersystem ASSA är kanske inte det första företag du tänker på när det är dags att installera passersystem?

Läs mer

Praesideo digitalt högtalar- och utrymningslarmssystem Få fram ert budskap vad som än händer

Praesideo digitalt högtalar- och utrymningslarmssystem Få fram ert budskap vad som än händer Praesideo digitalt högtalar- och utrymningslarmssystem Få fram ert budskap vad som än händer 2 Praesideo högtalar- och utrymningslarmssystem från Bosch Hålla allmänheten informerad och skyddad Med fler

Läs mer

Definition DVG A06. Varför operativsystem? Operativsystem. Översikt. - Vad är ett operativsystem?

Definition DVG A06. Varför operativsystem? Operativsystem. Översikt. - Vad är ett operativsystem? DVG A06 Operativsystem, mm Definition Den del av systemet som hanterar all hårdvara och all mjukvara. Kontrollerar: -alla filer -alla enheter -varje del av minnet -varje ögonblick av processortiden (-nätverk

Läs mer

Användarhandbok. Nero BackItUp. Ahead Software AG

Användarhandbok. Nero BackItUp. Ahead Software AG Användarhandbok Nero BackItUp Ahead Software AG Information om copyright och varumärken Användarhandboken till Nero BackItUp och innehållet i den är skyddat av copyright och tillhör Ahead Software. Alla

Läs mer

Gemensamma grunder för samverkan och ledning vid samhällsstörningar. - Strategisk plan för implementering

Gemensamma grunder för samverkan och ledning vid samhällsstörningar. - Strategisk plan för implementering Myndigheten för samhällsskydd och beredskap Strategisk plan 1 (6) Datum 20141125 Diarienr 2012-1845 version 1.1 Projekt Ledning och samverkan Enheten för samverkan och ledning Bengt Källberg Patrik Hjulström

Läs mer

Manual HSB Webb brf 2004 03 23

Manual HSB Webb brf 2004 03 23 TERMINOLOGI I Polopoly används ett antal grundläggande begrepp för publicering och hantering av information, eller innehåll som det också benämns. Nedan följer en kort genomgång av denna grundläggande

Läs mer

Användning av testautomation inom Extendas utvecklingsorganisation

Användning av testautomation inom Extendas utvecklingsorganisation Testautomation Användning av testautomation inom Extendas utvecklingsorganisation Agenda Presentation av Extenda Vad är en POS? Test av POS Automatiska tester Sammanfattning 2 Kort historik 1982 Extenda

Läs mer

Nokia C110/C111 nätverkskort för trådlöst LAN. Installationshandbok

Nokia C110/C111 nätverkskort för trådlöst LAN. Installationshandbok Nokia C110/C111 nätverkskort för trådlöst LAN Installationshandbok KONFORMITETSDEKLARATION Vi, NOKIA MOBILE PHONES Ltd, tillkännager under vårt ensamma ansvar att produkterna DTN-10 och DTN-11 uppfyller

Läs mer

VI ÄR WMD - THE WORKFLOW COMPANY Nordens ledande workflow specialister inom SAP Helt enkelt!

VI ÄR WMD - THE WORKFLOW COMPANY Nordens ledande workflow specialister inom SAP Helt enkelt! VI ÄR WMD - THE WORKFLOW COMPANY Nordens ledande workflow specialister inom SAP Helt enkelt! Det handlar om att spara tid, få överblick, förenkla arbetsprocesser, utnyttja resurser och i slutändan handlar

Läs mer

TOTAL IMMERSION D FUSION RUNTIME LICENSAVTAL FÖR SLUTANVÄNDARE

TOTAL IMMERSION D FUSION RUNTIME LICENSAVTAL FÖR SLUTANVÄNDARE TOTAL IMMERSION D FUSION RUNTIME LICENSAVTAL FÖR SLUTANVÄNDARE Läs noga igenom alla villkor i detta licensavtal (nedan kallat avtalet ) mellan TOTAL IMMERSION och dig själv (nedan kallad du eller LICENSTAGARE

Läs mer

Säkerhetskopiering och återställning Användarhandbok

Säkerhetskopiering och återställning Användarhandbok Säkerhetskopiering och återställning Användarhandbok Copyright 2007-2009 Hewlett-Packard Development Company, L.P. Windows är ett USA-registrerat varumärke som tillhör Microsoft Corporation. Informationen

Läs mer

Kursplaner för Administartör IT-System Innehåll

Kursplaner för Administartör IT-System Innehåll Kursplaner för Administartör IT-System Innehåll Hårdvara och operativsystem (15 Yhp)... 2 Advanced Enterprise System Administration (25 yhp)... 2 Advanced Linux Security (25 yhp)... 2 CCNA (35 yhp)...

Läs mer

PARALLELLISERING AV ALGORITMER PROCESSORER FÖR FLERKÄRNIGA

PARALLELLISERING AV ALGORITMER PROCESSORER FÖR FLERKÄRNIGA PARALLELLISERING AV ALGORITMER FÖR FLERKÄRNIGA PROCESSORER 870928 3017 Johan Gustafsson 870303 4952 Gustaf David Hallberg 880525 8210 Per Hallgren 801117 0597 Wuilbert Lopez 1/7 Innehållsförteckning Table

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

Grundläggande datorkunskap

Grundläggande datorkunskap Grundläggande datorkunskap Vissa nybörjare känner sig väldigt osäkra Man kan förstora texten på skärmen genom att trycka på Ctrl + SeniorNet Lidingö 2014-11-10 Mamma får en gammal dator av sin son men

Läs mer

Datorarkitekturer. Sammanfattande bedömning. Ämnesbeskrivning

Datorarkitekturer. Sammanfattande bedömning. Ämnesbeskrivning Datorarkitekturer Sammanfattande bedömning Datorarkitektur är det teknikvetenskapliga ämne som behandlar principer för konstruktion av datorsystem. Datorns arkitektur definierar ett funktionellt gränssnitt

Läs mer

B r u k s a n v i s n i n g A I - 7 0 7 9 4 4

B r u k s a n v i s n i n g A I - 7 0 7 9 4 4 H A R D D I S K A D A P T E R I D E / S A T A T O U S B 2. 0 o n e t o u c h b a c k u p B r u k s a n v i s n i n g A I - 7 0 7 9 4 4 S U O M I H A R D D I S K A D A P T E R I D E / S A T A T O U S B

Läs mer

H A R D D I S K A D A P T E R I D E / S A T A T O U S B 3. 0 O N E T O U C H B A C K U P

H A R D D I S K A D A P T E R I D E / S A T A T O U S B 3. 0 O N E T O U C H B A C K U P H A R D D I S K A D A P T E R I D E / S A T A T O U S B 3. 0 O N E T O U C H B A C K U P B R U K S A N V I S N I N G A I - 7 0 7 9 4 5 S U O M I H A R D D I S K A D A P T E R I D E / S A T A T O U S B

Läs mer

GSL 1000. Elektroniskt högsäkerhetslås för värdeskåp, valv och dörrar

GSL 1000. Elektroniskt högsäkerhetslås för värdeskåp, valv och dörrar GSL 1000 Elektroniskt högsäkerhetslås för värdeskåp, valv och dörrar GSL 1000 GSL 1000 är ett otroligt flexibelt elektroniskt högsäkerhetslås som kan användas som en fristående enhet, som ett lås med engångskoder

Läs mer

Nero AG Nero DiscCopy

Nero AG Nero DiscCopy Användarhandbok för Nero DiscCopy Nero AG Nero DiscCopy Information om upphovsrätt och varumärken Användarhandboken till Nero DiscCopy och dess innehåll skyddas av upphovsrätt och tillhör Nero AG. Med

Läs mer

Introduktion till programmering. Undervisning. Litteratur och examination. Lärare. Föreläsning 1

Introduktion till programmering. Undervisning. Litteratur och examination. Lärare. Föreläsning 1 Kursinfo Introduktion till programmering Undervisning Föreläsning 1 Kursinformation Inloggning, filsystem, kommandotolk några inledande exempel Föreläsningar Fem föreläsningar, vardera 45 minuter. Allmänna

Läs mer

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 Document: STG/PS K 525SV1 Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 SIS, Projekt Kvalitetsledning 1 1) Introduktion Produktstöd Två av de viktigaste målsättningarna i arbetet

Läs mer

Security Products Partnerprogram

Security Products Partnerprogram Security Products Partnerprogram Answers for infrastructure. Security Products Partnerprogram med oss är du säker Security Products är ett affärsområde inom Siemens AB, Building Technologies Division och

Läs mer

men borde vi inte också testa kraven?

men borde vi inte också testa kraven? men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av

Läs mer

Divar. Användningsguide. Divar application guide

Divar. Användningsguide. Divar application guide Divar Användningsguide Bosch Divar application Divar Digital guide mångsidig inspelare, DVR Bosch Divar Digital mångsidig inspelare, DVR Divar är den digitala inspelare som gör digital CCTV överkomlig

Läs mer

Henrik Asp. Allt du behöver veta för att KÖPA DATOR

Henrik Asp. Allt du behöver veta för att KÖPA DATOR Allt du behöver veta för att KÖPA DATOR Henrik Asp DEL 1 KOMPONENTER OCH PROGRAMVARA DEL 3 EFTER KÖPET 1. INTRODUKTION TILL BOKEN... 3 2. DATORNS HISTORIA... 4 A. Pc...5 B. Mac...6 C. HTPC...7 3. DATORNS

Läs mer

Guide för Innehållsleverantörer

Guide för Innehållsleverantörer Library of Labs Content Provider s Guide Guide för Innehållsleverantörer Inom LiLa ramverket är innehållsleverantörer ansvariga för att skapa experiment som "LiLa Learning Objects", att ladda upp dessa

Läs mer

Hi-O. Intelligent teknologi för dörrmiljöer. ASSA ABLOY, the global leader in door opening solutions.

Hi-O. Intelligent teknologi för dörrmiljöer. ASSA ABLOY, the global leader in door opening solutions. Hi-O Intelligent teknologi för dörrmiljöer ASSA ABLOY, the global leader in door opening solutions. 1 Vad är Hi-O? Innehåll Hi-O, Highly intelligent opening, är en standardiserad teknologi som gör att

Läs mer

Sentrion intelligent säkerhet

Sentrion intelligent säkerhet Sentrion intelligent säkerhet www www IP-kamera Mobilgränssnitt Internet Befintligt nätverk SIOM Dörr-/larmnod Sentrion Centralenhet www Dörr-/larmnod SIOM Larm Sentrion marknadens mest intelligenta säkerhetssystem

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

Java Programmer for JDK 1.1 1997 Developer for Java 2 Platform 2002

Java Programmer for JDK 1.1 1997 Developer for Java 2 Platform 2002 Systemarkitekt/systemutvecklare Trevor Lyall arbetar som systemarkitekt och senior systemutvecklare. Han har en lång och bred erfarenhet av projekt inom flera olika branscher. Med sitt djupa intresse för

Läs mer

ANVÄNDAR MANUAL. SESAM 800 RX MC Manager

ANVÄNDAR MANUAL. SESAM 800 RX MC Manager ANVÄNDAR MANUAL SESAM 800 RX MC Manager Åkerströms Björbo AB Box 7, SE-780 45 Gagnef, Sweden street Björbovägen 143 SE-785 45 Björbo, Sweden Phone +46 241 250 00 Fax +46 241 232 99 E-mail sales@akerstroms.com

Läs mer

Allmänt om programvaror och filer i Windows.

Allmänt om programvaror och filer i Windows. Allmänt om programvaror och filer i Windows. Vart sparade du dokumentet? I Word. Jag har fått detta svar mer än en gång när jag försökt hjälpa någon att hitta ett dokument som de tappat bort i sin dator.

Läs mer

TNK046 GIS - Databaser Laborationsuppgift 1 Introduktion till Microsoft Access 2007

TNK046 GIS - Databaser Laborationsuppgift 1 Introduktion till Microsoft Access 2007 Linköpings tekniska högskola ITN / Campus Norrköping Jan Petersson Uppdaterad av Marky Egebäck 17 november 2009 TNK046 GIS - Databaser Laborationsuppgift 1 Introduktion till Microsoft Access 2007 Översikt

Läs mer

Molnbaserad B2B: Minska kostnader och integrera fler partners!

Molnbaserad B2B: Minska kostnader och integrera fler partners! Molnbaserad B2B: Minska kostnader och integrera fler partners! Dagens globala affärslandskap översvämmas av interaktionspunkter mellan partners. Verksamheter av olika storlekar försöker kontinuerligt optimera

Läs mer

RadioFrekvensIdentifiering (RFID)

RadioFrekvensIdentifiering (RFID) SIS/TK446 Automatisk Identifiering och Datafångst En teknik för automatisk identifiering och datafångst Resumé Detta dokument ger en kort överblick av, vad det är, systemet, frekvenser, en jämförelse med

Läs mer

Din guide till. Teknisk Specifikation Säljstöd

Din guide till. Teknisk Specifikation Säljstöd Din guide till Teknisk Specifikation Säljstöd April 2014 Innehåll Systemkrav... 3 Operativsystem... 3 Mjukvara... 3 Maskinvara... 4 Datakällor... 4 Databas... 5 Databasstruktur... 5 Katalogstruktur...

Läs mer

Daniel Akenine, Teknikchef, Microsoft Sverige

Daniel Akenine, Teknikchef, Microsoft Sverige Daniel Akenine, Teknikchef, Microsoft Sverige Quincy Invånare: 5,300 Arbete: 52% jordbruk 18 % byggsektor 18 % offentlig sektor Språk: Spanska 57% Företaget Inköp Företaget Inköp Installering Lång

Läs mer

Välkomna! Med utveckling menas som bekant åsiktsförändring i för bedömaren behaglig rikting. Hjalmar Söderberg

Välkomna! Med utveckling menas som bekant åsiktsförändring i för bedömaren behaglig rikting. Hjalmar Söderberg 2014 09 18 Kvalitets och miljösystem? Välkomna! Vad är ett kvalitets miljösystem? Varför i byggprocessen? (Vad består ett kvalitets miljösystem av?) Genomgång av uppgiften kopplad till modul kretslopp...

Läs mer

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning En rapport från CATD-projektet, januari-2001 1 2 Förstudie Beslutsstöd för operativ tågtrafikstyrning Bakgrund Bland de grundläggande

Läs mer

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år Javautvecklare 400 YH-poäng, 2 år Utbildningsfakta Kurser (12 stycken) Grundläggande programmering och javaverktyg 50 yhp Grafiskt gränssnitt och interaktion 20 yhp Internet, webb och webbramverk 40 yhp

Läs mer

Bewator OMNIS version 6.1 Produkt release information

Bewator OMNIS version 6.1 Produkt release information Bewator OMNIS version 6.1 Produkt release information Nyheter i version 6.1 Nya möjligheter vid bokningar I Omnis version 6.1 finns möjligheten att reservera mer än en behörighetsgrupp för bokningar. Nya

Läs mer

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström.

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Författare Per Johansson, Henrik Wallinder Generellt Helhetsintrycket från genomläsning av uppsatsen

Läs mer

Kort om kursplanen i teknik

Kort om kursplanen i teknik Kort om kursplanen i teknik är ett sammandrag av Skolverkets kursplan i teknik från Läroplan för grundskolan, förskoleklassen och fritidshemmet 2011 1 samt Kommentarmaterial till kursplanen i teknik 2.

Läs mer

Processbeskrivning Test

Processbeskrivning Test ProcIT-P-017 Processbeskrivning Test Lednings- och kvalitetssystem Fastställt av Sven Arvidson 2012-06-20 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Testprocessen 4 2.1

Läs mer

EVRY One Outsourcing Linköping AB. Erfaranheter av daglig drift och nyttjande av IFS Applications 8.

EVRY One Outsourcing Linköping AB. Erfaranheter av daglig drift och nyttjande av IFS Applications 8. EVRY One Outsourcing Linköping AB Erfaranheter av daglig drift och nyttjande av IFS Applications 8. Vår erfarenhet IFS Applications 8 Ca 10 st genomförda eller pågående uppgraderingar till IFS 8. Första

Läs mer

Kristian Almgren Artificiell Intelligens Linköpings Universitet 2011. Talstyrning

Kristian Almgren Artificiell Intelligens Linköpings Universitet 2011. Talstyrning Talstyrning Abstrakt Talstyrning är en teknik som gör det möjligt för oss människor att mer eller mindre verbalt kommunicera med en dator eller ett system. Det här är ett tillvägagångssätt inom AI och

Läs mer

Anpassningsbar applikationsstruktur för flerpunktsskärmar

Anpassningsbar applikationsstruktur för flerpunktsskärmar Datavetenskap Opponent(er): Rikard Boström Lars-Olof Moilanen Respondent(er): Mathias Andersson Henrik Bäck Anpassningsbar applikationsstruktur för flerpunktsskärmar Oppositionsrapport, C/D-nivå 2005:xx

Läs mer

Motion om fri mjukvara

Motion om fri mjukvara Motion om fri mjukvara Fri mjukvara 1 är gratis 2. Fri mjukvara sparar kommunen pengar 3. Sverigedemokraterna Oskarshamn föreslår kommunfullmäktige: Att planera för en övergång till fri mjukvara, själv

Läs mer

Professional Services. Linux Support Group (LSG)

Professional Services. Linux Support Group (LSG) Professional Services Linux Support Group (LSG) Att införa Embedded Linux Har du problem att få igång Linux på din plattform? Du har kanske inte kommit så långt, men funderar på vad det innebär att bygga

Läs mer

Systemskiss. LiTH Autonom bandvagn med stereokamera 2010-09-24. Gustav Hanning Version 1.0. Status. TSRT10 8Yare LIPs. Granskad

Systemskiss. LiTH Autonom bandvagn med stereokamera 2010-09-24. Gustav Hanning Version 1.0. Status. TSRT10 8Yare LIPs. Granskad Gustav Hanning Version 1.0 Status Granskad Godkänd Jonas Callmer 2010-09-24 1 PROJEKTIDENTITET 2010/HT, 8Yare Linköpings tekniska högskola, institutionen för systemteknik (ISY) Namn Ansvar Telefon E-post

Läs mer

Inlämningsarbete Case. Innehåll Bakgrund bedömning inlämningsarbete... 2 Inlämnade arbeten... 4

Inlämningsarbete Case. Innehåll Bakgrund bedömning inlämningsarbete... 2 Inlämnade arbeten... 4 Inlämningsarbete Case Innehåll Bakgrund bedömning inlämningsarbete... 2 Inlämnade arbeten... 4 1 Bakgrund bedömning inlämningsarbete Syfte: Eftersom det står i betygskriterierna att för VG skall deltagaren

Läs mer

Spetskompetens inom systemintegration, SOA och systemutveckling

Spetskompetens inom systemintegration, SOA och systemutveckling Spetskompetens inom systemintegration, SOA och systemutveckling Mjukvarukraft är ett företag som inriktar sig på konsultation och systemutveckling baserad på och omkring Microsofts plattformar och produkter.

Läs mer

CAD. Ämnets syfte. Kurser i ämnet

CAD. Ämnets syfte. Kurser i ämnet CAD Ämnet cad (computer aided design) behandlar hur man använder olika programvaror för att konstruera och designa verkliga och virtuella objekt. I ämnet är geometri grunden för att, via skiss och ritteknik,

Läs mer

Aditro Summit 2013-10-25 Erbjudande förflyttning Personec S till L Per Johansson. 2013-10-28 Copyright Aditro. All rights reserved.

Aditro Summit 2013-10-25 Erbjudande förflyttning Personec S till L Per Johansson. 2013-10-28 Copyright Aditro. All rights reserved. Aditro Summit 2013-10-25 Erbjudande förflyttning Personec S till L Per Johansson 2013-10-28 Copyright Aditro. All rights reserved. 1 Agenda» Presentation» Bakgrund» Erbjudandets innehåll» Leveransmodell»

Läs mer