Distribuerad utveckling. och. Configuration Management

Transkript

1 Distribuerad utveckling och Configuration Management Ulf Asklund, Lunds Tekniska Högskola, i samarbete med en stödkommitté från Sveriges Verkstadsindustrier, 1999

2

3 3 Förord Denna rapport har utarbetats på uppdrag av Sveriges Verkstadsindustrier (VI). De frågor som rapporten söker besvara har formulerats av VI:s TeknikRåd 12, "Systemkonstruktion i programvara", samt av studiens stödkommitté. Projektet finansierades av VI och NUTEK inom ramprogrammet Komplexa tekniska system. Studien har genomförts från april 1998 till februari 1999 av Ulf Asklund. Den baseras på intervjuer med personer inom industrin, på studier av forskningsrapporter och facklitteratur inom området, samt stödkommitténs och författarens samlade erfarenheter. Det bör framhållas att de intervjuade personerna uttryckt sina personliga uppfattningar, de representerar inte nödvändigtvis en officiell företagsposition. Stödkommittén har styrt studiens inriktning och även granskat och godkänt den slutliga rapporten. Författaren önskar tacka stödkommittén samt övriga personer och företag som medverkat till denna rapport. Ledamöter i stödkommittén: Annita Persson, Ericsson Microwave Systems AB (ordförande) Ivica Crnkovic, ABB Automation Products AB Alf Ek, Ericsson Mobile Communications AB Olle Eriksson, Ericsson Business Consulting Sverige AB Benita Gadd, Celsius Tech Systems AB Jan-Ola Krüger, Saab AB, Gripen Thomas Nilsson, SoftLab AB Anders Olofsson, Combitech Software AB Jan Rosén, Volvo IT AB Ulf Asklund, Lunds Tekniska Högskola (projektledare/utredare) Göran Östlund, Sveriges Verkstadsindustrier (beställare) Adress till författaren: Ulf Asklund Institutionen för datavetenskap Lunds Tekniska Högskola Lund tel e-post: Ulf.Asklund@cs.lth.se Trevlig läsning!

4 4

5 5 Innehållsförteckning Sammanfattning Inledning Syfte Omfattning Läsanvisning Distribuerad utveckling Fall av distribuerad utveckling Konfigurationsledning (CM) Strategier/arbetssätt CM ur ledningsperspektiv CM ur utvecklarperspektiv - verktygsstöd Sammanfattning Synkroniseringsmodeller Checkout/checkin Composition Långa transaktioner Change set Verktygsstöd för synkroniseringsmodeller Sammanfattning Arkitekturer Lokalt mot en server Fjärranslutning Bärbar dator mot en server Flera siter med Master-Slave koppling Flera siter med olika ansvarsområden Flera siter med likvärdiga servrar Diskussion Sammanfattning Erfarenheter och tips kring nyckelområden Parallell utveckling och awareness Hantering av ändringar Inkrementell utveckling Sekretess och säkerhet Datalagring, arkiv Integration och leverans Konsistenta utvecklingsmiljöer Forskning & Trender Forskning & Trender Konferenser och journaler Verktyg ClearCase Continuus CVS ExcoConf

6 6 8.5 JavaSafe PCMS PVCS Teamware TRUEchange Visual SourceSafe Tips vid införande av verktygsstöd Intervjuer Inledning Frågeställningar ABB Automation Products ABB Robotics Products Combitech Software Enator Ericsson Microwave Systems AB Ericsson Mobile Communications Ericsson Telecom Factum Elektronik AB Kockums Computer Systems Saab Gripen Telelogic Referenser Index

7 7 Sammanfattning Denna rapport behandlar problemställningar inom konfigurationsledning (CM - Configuration Management) i samband med distribuerad programvaruutveckling. Rapporten riktar sig till den som står i begrepp att, eller redan har, infört distribuerad utveckling. Rapporten innehåller dels en teoretisk del och dels en översikt över hur några svenska företag, som redan kommit en bit på väg, hanterar dessa frågor. Rapporten fungerar därmed både som en "state of the art" och en "best practice" beskrivning. Distribuerad CM har mycket snabbt fått stor betydelse, inte minst genom utvecklingen av Internet. Rapporten kan därför vara värdefull även för den som redan utnyttjar distribuerad utveckling i någon form. De områden som rapporten fokuserar på är: hur arbetssättet bör se ut för att klara distribuerad programvaruutveckling, olika arkitekturer för organisation av datormiljö, de konsekvenser bortfallet av informella kontaktytor får, en kortfattad presentation och karaktäristik av några typiska CM-verktyg, begränsningar hos nuvarande tekniker, tips vid införande av verktygsstöd. Rapporten ger förslag till lösningar inom presenterade problemområden och visar att distribuerad utveckling har en potential att utnyttjas på ett effektivt sätt och användas i stor skala. Mycket av innehållet i rapporten baseras på intervjuer av företag. De lösningar som föreslås är av praktisk karaktär och används redan inom svenska företag. Arbetssätten är alltså etablerade och sprids nu också till mindre företag i takt med att infrastrukturen blir tillgänglig och CM-verktygen kommer ner i pris. Alla verkar vara överrens om att det alltid är enklast att utveckla lokalt. I många fall kan man dock inte välja och trenden är att allt fler företag får en distribuerad miljö. En trend är dock att allt fler medvetet skapar förutsättningar för distribuerad utveckling, för att på så sätt bättre kunna utnyttja resurser inom företaget, oavsett var de arbetar. Tidigare var en distribuerad situation oftast en konsekvens, t ex av en företagssammanslagning. Distribuerad utveckling medför oftast utnyttjande av långsammare och mindre tillförlitliga nätverk. Det medför också minskade möjligheter till kommunikation genom informella kontakter mellan grupper och individer. Sådana kontakter (t ex under lunchen eller i kafferummet) har stor betydelse för hur vi hanterar oväntade situationer. Lika viktigt som att veta vilken metodik som finns tillgänglig och vad den kan, lika viktigt är det att veta vad den inte kan och vad som fungerar mindre bra. Nu tillgängliga metoder och verktyg medför begränsningar i hur flexibelt man kan arbeta i distribuerade situationer. T ex finns idag viktiga brister i teknikstöd för distribuerade grupper, dvs för personer som arbetar tätt samman, men som sitter geografiskt åtskilda. Rent tekniskt fungerar det bättre i situationer där medlemmarna i en grupp sitter på samma plats, men olika grupper kan finnas på olika ställen. Dock skall man även här vara medveten om de

8 8 problem som kan uppstå genom minskad informell kommunikation och information mellan grupperna. Det är viktigt att påpeka att rapporten inte ger alla och inte ger absoluta svar. Området är aktivt forskningsmässigt och man kan förvänta sig en stark utveckling inom de närmaste åren.

9 9 1 Inledning Stora företag och organisationer har under lång tid haft tillgång till globala nätverk, men den snabba utvecklingen av Internet har inneburit en radikalt ökad tillgång till sådana tjänster. Detta innebär en tillgänglighet till den grad att den förutsätts vid snart sagt allt arbete och då inte minst programvaruutveckling. Grupper av utvecklare kan nu sitta världen över och arbeta med utveckling av samma system. Från olika platser kan de behöva modifiera tusentals filer, och ibland samma filer, i en och samma produkt. Potentialen är stor genom ökande möjligheter att utnyttja personal och kompetens effektivare, flexiblare och med ökad bekvämlighet. Samtidigt har denna nya teknik inneburit stora förändringar av arbetets organisation i andra sammanhang, och så också här. Sättet att dela upp arbetet och hur samspelet mellan grupper och individer hanteras påverkas starkt av att personalen är geografiskt utspridd. Detta ställer nya krav på de verktyg och system som används för att hantera koordination av utvecklingen och då alldeles speciellt vid parallell utveckling. Mycket av dessa behov faller inom området Konfigurationsledning, som är ämnet för denna rapport, men inte enbart. Andra system för kommunikation och ledning påverkas naturligtvis också om personalen är geografiskt distribuerad över stora avstånd, men det är inte primärt i fokus här. Konfigurationsledning av programvara (SCM - Software Configuration Management) syftar bl a till att koordinera utvecklare mot ett gemensamt mål en uppgift som försvåras av att de är geografiskt åtskilda. Ett centralt problem är att hantera dokument och programs historia och utveckling över tiden samt hantera grenar och stödja sammanslagning (merge), t ex vid parallell utveckling. SCM har ursprungligen utvecklats under den mer eller mindre explicita förutsättningen att personer så väl som filer är placerade på en och samma geografisk plats. Detta gäller såväl de verktyg som utvecklats, som de arbetsprocesser man tillämpat. Den allmänna uppfattningen om vilken funktionalitet som förknippas med SCM är också formad utifrån denna förutsättning. Andra aspekter av systemutveckling, som skapande av helhetsbild och sammanhang, kommunikation mellan utvecklare och grupper, har förblivit manuella och utan direkt verktygsstöd. Delar av detta behov har täckts av fristående dokument, specifikationer, och formella sammanträden där viktiga beslut fattas. Men förvånansvärt mycket av detta behov av information för synkronisering, både inom och mellan grupper, täcks av informella kontakter utvecklare emellan, under diskussioner, på granskningsmöten, under kaffepausen, i korridoren, m m. När personer som arbetar tätt tillsammans är geografiskt spridda behöver vi tänka över hur dessa övriga aspekter också kan stödjas både i arbetsgång och verktygsstöd. Ju tätare samman personer arbetar (trots det geografiska avståndet) och ju mer beroende deras olika arbetsuppgifter är, desto tydligare blir bristen på stöd. En god strategi vid all utveckling är att försöka begränsa beroendena mellan utvecklare, och då speciellt om de befinner sig på olika platser. Detta görs oftast redan vid struktureringen av den produkt som ska utvecklas. Systemet delas upp i olika moduler eller komponenter vilka sedan utvecklas av olika grupper var för sig. Det visar sig dock att det, trots god struktur, finns beroenden kvar mellan komponenterna. Det visar sig inte minst när gränssnitt behöver modifieras eller när delarna skall integreras. Detta är

10 10 1 Inledning exempel på situationer där man, även om man försöker undvika det, ställer krav på överblick och synkronisering mellan grupper som vi nämnde ovan. Dessutom finns problem som inte direkt är kopplade till modulariseringen, som t ex sekretess, ändringshantering och hantering av originalarkiv som även de kräver speciell hänsyn vid distribuerad utveckling. I denna rapport visar vi genom ett antal exempel på olika situationer då distribuerad utveckling kan uppstå i ett företag. Det kan vara allt från distansarbete från hemmet till fullständiga utvecklingsmiljöer på olika dotterbolag eller vid s k outsourcing. Vi klassificerar några olika fall och belyser deras specifika egenskaper. Vidare beskriver vi olika arkitekturer, arbetsprocesser och verktyg och på vilket sätt dessa stödjer distribution i de olika fallen. Med hjälp av företagsintervjuer har vi kartlagt redan idag använda metoder och verktyg, hur de används i de olika företagen och deras erfarenheter av detta. På så sätt redovisar vi en "best practice" från företagen. I slutet av rapporten ges tips om hur man gör en självutvärdering som ett första steg i införandet av föreslagna rutiner och verktyg i en befintlig miljö. Vi ger också en kort inblick i var forskningen i området står idag och försöker även titta lite in i framtiden för att skissera vilka lösningar som kan tänkas finnas när behoven växer. Mycket av den teori som tas upp i denna rapport är inte begränsat till programvara, utan kan även appliceras på andra produkter och dokument. Vi kommer därför fortsättningsvis att benämna konfigurationsledning med förkortningen "CM" (Configuration Management) i stället för SCM. 1.1 Syfte En tidigare utredning av Sveriges Verkstadsindustrier, Konfigurationshantering. Motiv och nytta - erfarenheter från svensk industri inom programvaruområdet [Nym96], behandlar konfigurationsledning i allmänna termer. Fokus där är grundläggande CM, motiv och nytta speciellt som det rapporterats från svensk industri. För grundläggande frågor om CM för programvara hänvisar vi till denna rapport. Syftet med en ny rapport är att fokusera på CM-området i samband med distribuerad utveckling, ett område som utvecklats starkt sedan den förra rapporten skrevs. Mer precist är syftet med denna rapport att: studera det för industrin viktiga delområdet CM vid distribuerad utveckling av programvara, förmedla kunskap inom CM-området till svensk industri, rapportera vad som hänt under senaste året inom CM-området både nationellt och internationellt, följa trender inom CM-området både nationellt och internationellt. Rapporten vänder sig främst till CM-ingenjörer, projektledare, företagsledning och andra i motsvarande ställning.

11 1.2 Omfattning Omfattning De delområden som behandlas, då med fokusering på distribuerad utveckling av programvara, är: arbetssätt erfarenhet införande verktyg Rapporten bygger dels på intervjuer hos 11 svenska företag med erfarenhet från införande av distribuerad utveckling, och dels på tillgänglig litteratur och forskningspublikationer i området. Intervjuerna skedde under 1998 och har genomförts med ca en dags diskussion som sedan följts av en eller flera iterationer för att verifiera, korrigera och komplettera beskrivningarna. 1.3 Läsanvisning Denna rapport är inte en inledande beskrivning av konfigurationsledning (CM) i allmänhet. För en sådan hänvisas till [Nym96]. Rapporten är strukturerad så att de inledande avsnitten (1-5) är av teoretisk karaktär utan värderingar. Terminologi införs som sedan används i resten av rapporten. Förhoppningsvis är innehållet i dessa avsnitt relativt beständigt över tiden. Resterande avsnitt (6-10) är av mer praktisk karaktär. Olika problem och lösningar diskuteras vilka värderas med utgångspunkt från det vi idag känner till. Avsnitt 2 - Distribuerad utveckling Beskriver olika fall av distribuerad utveckling och namnger dessa. Avsnitt 3 - Konfigurationsledning (CM) Beskriver konfigurationsledning ur lednings- och utvecklarperspektiv. Termer som utvecklings-, parallell utvecklings- och uppdateringsstrategi införs. Avsnitt 4 - Synkroniseringsmodeller Teoriavsnitt som beskriver fyra synkroniseringsmodeller, dvs olika sätt att stödja synkroniseringen av samtidiga, parallella, ändringar från olika användare. Modellerna är viktiga abstraktioner och kan vid en diskussion fungera bättre än ett verktygs enskilda funktioner. Vid en första snabb genomläsning kan det kanske räcka med sammanfattningen. Avsnitt 5 - Arkitekturer Beskriver olika arkitekturer med klienter, servrar och platser (siter).

12 12 1 Inledning Avsnitt 6 - Erfarenheter och tips kring nyckelområden Innehåller vår definition av några nyckelområden och de problem som geografisk spridning kan ge upphov till. Dessutom erfarenheter från de intervjuade företagen, samt konkret och praktisk vägledning. Avsnitt 7 - Forskning & Trender En kort översikt över vad som hänt de senaste åren på några viktiga konferenser i området. Avsnitt 8 - Verktyg Några utvalda verktyg presenteras kort, framför allt deras stöd för parallell- och distribuerad utveckling. Avsnitt 9 - Tips vid införande av verktygsstöd Några korta tips vid införandet av ett nytt CM-verktyg. Avsnitt 10 - Intervjuer Redovisar gjorda intervjuer. Rapporten kan också användas för att slå upp, t ex hur en viss synkroniseringsmodell fungerar, eller hur något speciellt företag arbetar (i det projekt som beskrivs).

13 13 2 Distribuerad utveckling Med distribuerad utveckling menas i denna rapport den situation som uppkommer då utvecklare, eller grupper av utvecklare, som arbetar med att utveckla samma programvarusystem sitter geografiskt åtskilda. Det omfattar allt från olika delar av samma stad till skilda världsdelar med olika tidszoner. Som följd av detta riskerar man att bli beroende av ett långsammare och mindre tillförlitligt nätverk, och som konsekvens kanske tvingas kopiera gemensamma filer med alla de problem detta kan medföra. Geografisk åtskildhet medför dessutom minskade möjligheter till möten, formella såväl som informella, som t ex vid kaffepauser. Detta innebär att den informella kontaktytan mellan grupper minskas med mindre kunskap om övergripande sammanhang mellan delprojekt som följd. Det innebär också att gruppgemenskapen (teamkänslan) vid distribution riskerar att försvagas vilket försvårar kontakter mellan grupperna vid t ex problem med ett gemensamt gränssnitt. Situationen ställer alltså nya krav på hur gemensamma data, t ex filer, hanteras, men också hur information kan spridas mellan och inom grupper av utvecklare. De tekniska problemen med distribuerad utveckling kanske enklast illustreras med hanteringen av en bärbar dator. Här är det vanligt att man använder tekniken med (ofta manuell) replikering av filmassan. Detta innebär att man kopierar de filer man tror sig behöva till den bärbara datorn. Filmassan modifieras på båda datorerna och behöver därefter en efterföljande synkronisering (dvs att välja senaste upplaga av ändrade filer). Om enskilda filer ändrats på båda datorerna måste dessa mergas (dvs ändringarna i dessa filer ensas). Problemet växer med storleken på filmassan, tiden mellan synkroniseringar, och i det mer generella fallet, med antalet kopior. Förutom nya krav på verktyg och arbetssätt för utvecklarna så ställer distribuerad utveckling också nya krav på kommunikation vertikalt och horisontellt i organisationen samt projektledning; styrning, uppföljning, rapportering. Några av de uppkomna problemen i samband med distribuerad utveckling kan kompenseras genom förändringar i den utvecklade produktens design, förbättrad arbetsmodell och/eller genom att utnyttja speciell funktionalitet i det CM-verktyg som används. Man kan försöka eliminera inflytandet av den nya situationen genom att agera som om man inte har distribuerad utveckling. Ett sätt att uppnå detta är att centralisera hanteringen av uppdateringar genom att göra en person ansvarig för varje fil, modul eller delsystem. Fördelen med detta är att alla tekniska problem med distribution av programvaran försvinner. Nackdelarna är emellertid att utvecklingen kan komma att bli tungrodd, trög och långsam vilket kan leda till att mindre viktiga, men kanske enkla, förändringar aldrig genomförs. Vidare har inte den person som står med problemet något inflytande över vilka ändringsförslag som prioriteras. Slutligen blir kompetensen mindre spridd än om man t ex har en grupp som är ansvarig, vilket kan leda till problem vid personalförändringar. Man kan försöka anpassa sig till de nya villkoren och göra sig mindre beroende av de aspekter som försämras, t ex göra de som arbetar geografiskt utspridda mindre beroende av varandra. Genom att dela upp den gemensamma produkten i så

14 14 2 Distribuerad utveckling oberoende komponenter som möjligt, minskar man behovet av kommunikation mellan åtskilda utvecklare av respektive komponent. Trots detta visar det sig dock att de ibland i alla fall måste arbeta (åtminstone tillfälligt) i samma delprojekt och då kanske t o m i samma filer. Ett annat sätt att minska behoven av kommunikation mellan geografiskt åtskilda utvecklare är att alla utvecklingsorter har en fullständig kopia av all programvara. Då kan utvecklingen ske lokalt åtminstone tillfälligt, vilket minskar problemen i det dagliga arbetet. Denna lösning medför i stället en risk för divergerande gränssnitt med ökade svårigheter vid integration som följd. Arbetets art och avståndet mellan de åtskilda användarna av CM-systemet (utvecklare, projektledare etc) gör att olika krav ställs på CM-lösningen. Utvecklaren som arbetar hemma på kvällen och stöter på problem träffar sina kolleger på morgonen dagen efter och behöver i mindre grad kommunikationsstöd från systemet. Sitter man i olika hus i samma stad känner man kanske varandra och har därför lättare för att ta kontakt än om det rör sig om olika länder. Kommunikation över tidszoner ger extra besvär. Vi ska i detta avsnitt ta upp några vanliga situationer då distribuerad utveckling uppstår och beskriva vad som är karakteristiskt för var och en av dessa. Senare i rapporten klassificerar vi även några olika klient/server-arkitekturer för CM-system och tittar på deras för- och nackdelar med avseende på distribuerad utveckling. Distribuerad utveckling påverkar mer än applikationens arkitektur. Exempelvis påverkas också hanteringen av ändringar, hur man hanterar originalarkiv, implementering av inkrementell utveckling, m m. En mer detaljerad behandling av dessa områden ges i avsnitt 6, "Erfarenheter och tips kring nyckelområden". 2.1 Fall av distribuerad utveckling Distribuerad utveckling kan uppstå av många olika anledningar. Vi ska i detta stycke försöka klassificera dessa anledningar i några få karakteristiska fall. Vår förhoppning är att man här kan känna igen något eller några av fallen som då indikerar att man redan har, eller är på väg att införa en distribuerad utveckling. En klassificering underlättar också en diskussion om lösningsförslag och senare resonemang i denna rapport. De olika fall som identifierats är: Lokalt (för jämförelse) Distansarbete Kontrakterad utveckling (Outsourcing) Sammanhållna grupper på olika platser Distribuerade grupper med medlemmar på olika platser De olika fallen förekommer var och en för sig eller i kombinationer. T ex kan man normalt ha sammanhållna grupper, men då och då även få fallet med en distribuerad grupp.

15 2.1 Fall av distribuerad utveckling Lokalt Karakteristiskt för en arbetsplats där alla sitter lokalt är ett snabbt nätverk vilket möjliggör full utvecklings- och testmiljö för alla utvecklare. Det är relativt lätt för projektgrupperna att kommunicera och synkronisera sitt arbete, både genom formella möten och genom mer informella träffar som t ex kring kaffebordet. Informella möten ger också en bra gruppgemenskap vilket i sin tur ökar sannolikheten att den fastställda CM-processen efterföljs. Ur CM-perspektiv: Ett gemensamt filsystem. Full utvecklings- och testmiljö. Synkronisering kan till viss del ske genom möten. Speciellt kan problem som uppstår lösas med direktkommunikation. Bra medvetenhet om vad andra gör ("group awareness"). Inga speciella sekretessproblem (externa nätverk utnyttjas i princip inte) Distansarbete Modem, CD/Tape, Bärbar dator Denna form av distansarbete är kortare arbetsinsatser som utförs på annan plats än den ordinarie. Hemarbete som komplement till det dagliga arbetet är det primära exemplet. Då utvecklare mer regelbundet och under en längre tid arbetar hemifrån (eller på annan plats) uppstår en situation som är mer lik den för distribuerade grupper, se Karakteristiskt för distansarbete är begränsad datorkraft och en relativt långsam kommunikation mot omvärlden (t ex via modem till den normala arbetsplatsen). Trots detta vill man snabbt kunna börja arbeta då den totala tiden per arbetstillfälle är kort (typiskt några timmar på kvällen), vilket innebär att arbetsmiljön måste kunna "sättas upp" snabbt. Eftersom de dagliga kontakterna bibehålls så är möjligheterna till informell kommunikation och teamkänslan i stort sett den samma som i den lokala situationen. Två vanliga arbetssätt är: Enstaka filer tas hem med vilka man arbetar lokalt. Nödvändigt arbetssätt då en fullständig miljö hemma tar för lång tid att uppdatera inför varje arbetstillfälle eller överhuvudtaget inte går att installera. Remote login mot arbetsplatsen och hemdatorn används som terminal.

16 16 2 Distribuerad utveckling Ur CM-perspektiv: Att ta hem enstaka filer gör att arbetet sker lokalt utanför CM-systemets kontroll och stöd. Vilken försämring detta ger beror lite på vilken synkroniseringsmodell verktyget stöder, se avsnitt 4, "Synkroniseringsmodeller". Exempelvis erbjuds inget stöd för medvetenhet om vad andra samtidigt gör. Dessutom omöjliggörs testning. Inloggning som terminal är ur CM-synpunkt likt det lokala fallet. Den långsammare förbindelsen gör arbetet något trögare för utvecklarna. En tendens är då att de kanske inte följer arbetsmodellen som de ska (t ex att före incheckning göra fullständig testning på alla plattformar) Kontrakterad utveckling (Outsourcing) kopiering av testmiljö ev. uppdatering av testmiljö leverans av komponent I stället för att utveckla allt själv eller köpa in befintliga komponenter (COTS - Commercial Off The Shelf) kan man låta någon tredje part utveckla dem åt sig. Det brukar kallas "outsourcing" och ger, jämfört med COTS, en större kontroll över komponentens utveckling, dock till ett högre pris. Outsourcing grundar sig på ett tätt samarbete mellan leverantör och beställare. Därmed brukar det ofta finnas möjlighet för utvecklaren/leverantören att redan före leverans testa komponenten i en miljö lik målmiljön. Testmiljön erhålls då vanligen från beställaren. Beställaren är i slutändan ansvarig för produkten och eventuell fel/ändringshantering från denna kan reflekteras i ändrade krav mot leverantören. Som vid alla beställningar måste man klargöra vad som skall levereras, men detta kompliceras här av att både krav och miljö kan förändras. Ur CM-perspektiv: beställare leverantör Beställaren ska kunna integrera nya versioner av komponenten i produkten, som själv kan ha utvecklats sedan förra frisläppningen av komponenten. Leverantören ska kunna hantera uppdatering av utvecklings- och testmiljö. Beställare och leverantör har nödvändigtvis inte samma CM-verktyg vilket kan göra uppdateringar (åt båda hållen) besvärliga. Vid leverans av källkod måste även genereringsverktyg vara konsistenta mellan beställare och leverantör. Vid ändrade krav måste samband mellan version av krav och leverans framgå.

17 2.1 Fall av distribuerad utveckling Sammanhållna grupper på olika platser Utvecklare på olika dotterbolag brukar tillhöra lokala grupper eller projekt. Uppdelningen av arbetet förbereds redan vid struktureringen av projektet/produkten för att förhindra alltför starka beroenden mellan de olika grupperna. Produkten delas upp i delprodukter vilka kan utvecklas av olika projektgrupper. Uppdelningen möjliggör att den mesta utvecklingen kan göras lokalt inom gruppen utan så mycket kommunikation med övriga grupper. Inom gruppen och mellan grupper på samma plats är situationen samma som vid lokal utveckling. Grupper på olika platser har normalt bara tillgång till de andra gruppernas senaste stabila versioner. På grund av det geografiska avståndet blir potentiella problem svårare att reda ut. Uppdatering och distribution mellan grupperna kräver därför mer omsorg och administration, de kan uppfattas som interna leveranser, och tenderar därför att komma mera sällan. Samverkan mellan grupperna kan underlättas om arbetet planeras i faser kända för alla. Omvänt är omfördelning eller uppdelning av arbetet i efterhand svårare att genomföra. Ur CM-perspektiv: Filerna lagras på olika filsystem, men (idealt) i samma CM-system. Stora företag har ibland olika CM-system i de olika dotterbolagen. Då platserna är permanenta bör varje grupp lokalt kunna arbeta med full utvecklingsmiljö och möjlighet till testning. Grupperna levererar (frisläpper) delprodukter mellan sig snarare än utvecklar tillsammans. Ofta ingen eller liten oplanerad daglig kontakt mellan grupperna. Kontakten begränsas till t ex veckomöten vilka kan vara fysiska möten eller telefon/videokonferenser. Det är viktigt att vidmakthålla en kunskap om utvecklingsstatus mellan grupperna. Ändringshanteringen av gemensamma komponenter, som t ex gränssnitt, är extra viktig Distribuerade grupper med medlemmar på olika platser Distribuerade grupper innebär att även gruppens medlemmar är distribuerade, dvs de personer som arbetar inom samma projekt, kanske t o m i samma filer, sitter geografiskt utspridda. Möjligheten till daglig kommunikation genom formella såväl som informella möten försvinner även inom gruppen. Projekt som arbetar mot samma produkt använder oftast några gemensamma bibliotek eller komponenter. Ändringar i dessa är ovan-

18 18 2 Distribuerad utveckling liga (just för att de är gemensamma och ändringar besvärliga att hantera), men ibland oundvikliga. Om gruppmedlemmar på olika platser samtidigt vill ändra kommer man i en situation liknande den för uppdatering av gränssnitt vid "sammanhållna grupper" men här gäller problemet alla filer. Situationen med distribuerade grupper är något man oftast försöker undvika, t ex genom att betrakta enstaka individer som mycket små sammanhållna grupper. Trots dessa strävanden finns det fall då grupper behöver arbeta tätt samman trots att de är distribuerade. Uppenbara exempel är då personer som ingår i en grupp av andra skäl måste resa runt till de andra grupperna. Givetvis vill man även då kunna arbeta vidare i sitt normala projekt, vilket då blir just i formen av en distribuerad grupp. En liknande situation uppstår när personal flyttas till nya projekt men ofta behöver konsulteras i de gamla. Personer med specialkompetens ingår ofta i flera grupper, eventuellt placerade på olika orter. Ur CM-perspektiv: Det är viktigt att gruppens medlemmar får information om vad de övriga i gruppen gör, hur projektet utvecklas, dess status, vilka ändringar som gjorts och av vem etc. Viktigt att stödja delning av filer och parallella, samtidiga ändringar. Lösningar med "låsning" och exklusiv tillgång till filer fungerar dåligt här eftersom det är tungt att lösa upp situationer där gruppens medlemmar, som är på olika platser, tvingas vänta på varandra Diskussion Situationen med lokal utveckling är naturligtvis att föredra ur CM-synpunkt då den är enklare att hantera än fallen med distribuerad utveckling. Det finns emellertid många andra goda skäl för de olika situationerna skisserade ovan. Situationen med sammanhållna grupper medför vanligen att arbetet planeras på ett sådant sätt att beroendet mellan grupper på olika platser minimeras. Situationen med distribuerade grupper är normalt inte eftersträvad utan det är snarare så att arbetets planering, hela systemkonstruktionen, uppdelning i komponenter, m m går ut på att undvika just detta fall. Trots det kan man förutse att situationen uppstår som en konsekvens av att sammanhållna grupper bryts upp. Ytterligare ett exempel är vid nyttjande av fjärrarbetsplatser, dvs en arbetsplats belägen närmare hemmet än den "riktiga" arbetsplatsen och som därför utnyttjas större delen av veckan. Situationen blir en blandning av distansarbete och distribuerade grupper. Typiskt fungerar de formella mötena, men de informella uteblir helt eller delvis.

19 3.1 Strategier/arbetssätt 19 3 Konfigurationsledning (CM) Innan vi fördjupar oss i distributionsaspekterna ska vi ge en kort introduktion till CM i allmänhet. För en mer omfattande introduktion hänvisar vi till den tidigare rapporten från Sveriges Verkstadsindustrier, Konfigurationshantering. Motiv och nytta erfarenheter från svensk industri inom programvaruområdet [Nym96]. Andra bra referenser som behandlar olika perspektiv av CM är [TF94, App98, Whi91, Kel96]. Den definition av CM som gjordes i förra VI-rapporten är: CM är det kontrollerade sättet att leda och hantera utveckling och förändring av sammansatta system och produkter, under hela deras livscykel. Det finns dock många andra definitioner, alla med lite olika fokus. En anledning till de olika definitionerna är att CM har två målgrupper med ganska olika krav: ledning (management) och utvecklare. Ur ledningsperspektiv styr och kontrollerar CM en produkts utveckling genom identifiering av produktkomponenter och kontroll över deras kontinuerliga förändringar. Målet är att dokumentera sammansättningen och status för en definierad produkt och dess ingående delar, samt att offentliggöra detta så att rätt arbetsunderlag används och att rätt produktsammansättning görs. Ett exempel på definition som stöder denna disciplin är ISO:s [ISO95] som menar att det huvudsakliga målet med CM är att dokumentera och att ge fullständig insyn i produktens aktuella konfiguration och status, avseende uppfyllandet av fysiska och funktionella krav. Ur utvecklarperspektiv (verktygsstöd) underhåller CM produktens aktuella komponenter, lagrar deras historia, erbjuder en stabil utvecklingsmiljö och koordinerar samtidiga ändringar i produkten. Målet är att göra en grupp av utvecklare så effektiva som möjligt i deras gemensamma arbete med produkten. CM omfattar både produkt (konfiguration) och arbetssätt (metoder).babich [Bab86] poängterar i sin definition det faktum att det ofta är en grupp utvecklare som tillsammans ska utveckla och underhålla ett system: Configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team. 3.1 Strategier/arbetssätt En överordnad aspekt för utformningen av CM-hanteringen är vilken utvecklingsstrategi man väljer när modifieringar av ett system ska göras. Strategin måste ta hänsyn till två i grunden motstridiga önskemål. Å ena sidan vill man åstadkomma att ändringar integreras tidigt så att eventuella problem upptäcks så fort som möjligt. Å andra sidan vill man ge utvecklarna en stabil miljö att arbeta i så att de inte i onödan störs i sitt arbete av tillfälliga fel åstadkomna av andra. Strategier som betonar det första önskemålet kan uppfattas som optimistiska problemen blir nog inte så stora, och strategier som betonar det andra önskemålet som konservativa integrationsarbetet är stort och komplicerat, så låt oss ta det så sällan som möjligt. Exempel på en optimistisk strategi är

20 20 3 Konfigurationsledning (CM) Daily build där alla dagens ändringar integreras mot dagens slut. Den som integrerar sist får också ta problemen. Exempel på en konservativ strategi är Big-bang integration som tenderar att göras sent, nära release, och då involverar alla utvecklare under en relativt lång och intensiv period. En relaterad aspekt är strategin för hur man skall tillåta parallellt arbete. En tidigare vanlig, konservativ, strategi är att inte tillåta parallella ändringar alls i samma filer (eller t o m delsystem). En optimistisk strategi är att tillåta sådana ändringar (mer eller mindre planerat) och att acceptera att en senare integration med ensning (merge) av ändringarna kan kräva visst arbete. Vi kan även tala om uppdateringsstrategi, dvs (a) hur man gör ändringar tillgängliga för andra, publicerar dem, och (b) vem som styr att ändringar faktiskt utnyttjas, prenumereras på. En optimistisk uppdateringsstrategi är att låta alla ändringar som publiceras också omedelbart utnyttjas av alla andra. Detta innebär att alla integrationsproblem måste lösas omedelbart (även om man försöker undvika problemen genom en omfattande process med t ex kodgranskning och tester innan publicering). En konservativ uppdateringsstrategi innebär att publicerade ändringar inte omedelbart slår igenom utan den som prenumererar på ändringarna kan styra när det skall ske, vilket innebär att det kan bli senare (tidigast då de upptäcker ändringen). Attityden till parallellt arbete i samma filer/delsystem har i många fall utvecklats från en konservativ till en alltmer optimistisk inställning i takt med att verktyg för versionshantering och merge kommit i allmänt bruk. I samband med distribuerad utveckling är en möjlighet till parallell utveckling, i åtminstone någon mån, närmast en förutsättning. En optimistisk uppdateringsstrategi kan kombineras med en konservativ utvecklingsstrategi. När man i en big-bang integration, efter noggrann analys, tror att man kartlagt alla integrationsproblem och fastlagt en ordning i vilken ändringarna skall integreras, så vill man omedelbart upptäcka om ytterligare, oförutsedda, problem uppstår. Omvänt kan en konservativ uppdateringsstrategi utnyttja en optimistisk utvecklingsstrategi. I t ex daily build integrerar man mot en gemensam utvecklingslinje, men ändringarna påverkar inte andra utvecklare förrän de påbörjar sin integration. Denna, och andra inkrementella utvecklingsstrategier, är optimistiska genom att de kör integrationsfasen ofta. Oavsett vilka strategier som passar bäst i en given situation så kommer den att genomsyra den utvecklingsmodell som utnyttjas, ställa krav på de verktyg som utnyttjas, och naturligtvis ställa krav på hur CM-arbetet utformas. Exempelvis kan en optimistisk uppdateringsstrategi medföra att modellen innefattar omfattande moment för kvalitetssäkring t ex genom kodgranskning och tester innan publicering samt att CM-arbetet, t ex dokumentation av ändringar, läggs upp så att spårning av ändringar och backning av systemet underlättas.

21 3.2 CM ur ledningsperspektiv CM ur ledningsperspektiv CM är en bred disciplin som täcker hela utvecklingsprocessen, både i tid (hela produktens livslängd) och omfattning (produkt och process). I detta avsnitt tar vi ett ledningsperspektiv och fokuserar på vad CM innebär ur denna synpunkt. Inte utan anledning är CM ett nyckelområde redan för nivå 2, för att uppnå repeterbarhet, enligt den kända CMM-modellen [SEI95]. Ansvarsområden inom Konfigurationsledning. Utdrag ur ISO [ISO95]. Konfigurering (Configuration Identification) Aktiviteter som innefattar fastställandet av en produktstruktur, valet av konfigurationsobjekt, dokumentationen av konfigurationsobjektens fysiska och funktionella karakteristika/egenskaper, inklusive gränsytor och senare förändringar, samt tilldelningen av identifierande bokstäver och siffror för konfigurationsobjekten och dessas dokument. Konfigurationsstyrning (Configuration Control) Aktiviteter omfattande styrning av ändringar i ett konfigurationsobjekt, sedan dess konfigurationsdokument formellt fastställts. Styrning innefattar utvärdering, samordning, godkännande eller avslag samt införande av ändringar. Ändringshantering innefattar konstruktionsändringar och hantering av avvikelser, samt dispenser som påverkar konfigurationen. Redovisning av konfigurationsstatus (Configuration Status Accounting) Formaliserad registrering och rapportering av fastställda konfigurationsdokument, status för föreslagna ändringar samt status för införandet av godkända ändringar. Statusredovisning bör tillhandhålla information om samtliga konfigureringar samt alla avvikelser från de specificerade baskonfigurationerna. Sålunda möjliggörs att ändringar gentemot baskonfigurationen blir spårbara. Konfigurationsrevision (Configuration Audit) Granskning för att avgöra huruvida ett konfigurationsobjekt överensstämmer med sina konfigurationsdokument. Funktionell konfigurationsrevision: en formell undersökning för att verifiera att ett konfigurationsobjekt har uppnått den prestanda och de funktioner som specificerats i dess konfigurationsdokument. Fysisk konfigurationsrevision: en formell undersökning för att verifiera att överensstämmelse råder mellan den faktiskt framtagna/producerade konfigurationen och konfigurationen enligt konstruktionsdokumenten. ISO95 beskriver också hur arbetsprocessen skall dokumenteras och fastläggas i en speciell CM-plan: En plan för konfigurationsledning har till syfte att användas inom organisationen, för specifika projekt eller av kontraktskäl.

22 22 3 Konfigurationsledning (CM) En plan för konfigurationsledning anvisar för varje projekt tillämpliga konfigurationsledningsrutiner samt anger vem som ska tillämpa dessa samt tidpunkt för tillämpningen. I en avtalssituation med flera nivåer är vanligtvis leverantörens plan för konfigurationsledning huvudplan. Varje underleverantör bör framställa sin egen plan, vilken kan publiceras som ett fristående dokument eller inkluderas i leverantörens plan. Kunden bör också ta fram en plan för konfigurationsledning, vilken beskriver kundens engagemang i leverantörens aktiviteter inom konfigurationsledningen. Det är absolut nödvändigt att alla sådana planer inbördes stämmer överens och tillsammans beskriver ett system för konfigurationsledning, vilket utgör grunden för tillämpningen av konfigurationsledning under projektets senare faser. Som framgår av dessa definitioner har CM till uppgift att strukturera arbetet dels på programutvecklingsnivå, dvs programutvecklingsprocessen, och dels på produktnivå, dvs i samband med leveranser (externa eller interna). CM-planens uppgift är att göra dessa rutiner tydliga, kända och naturligtvis avpassade så att de blir smidiga att arbeta efter. Effekt av geografisk spridning kommer in redan i dessa definitioner, t ex i CM-planens diskussion om leverantörer och beställare, men när det gäller programutvecklingsprocessen är de fyra punkterna för konfigurationsledning skrivna utan sådana överväganden. Detta hindrar inte att utformningen av en konkret CM-plan påverkas i högsta grad av att arbetet skall utföras i en distribuerad miljö. Konfigurering Vid distribuerad utveckling är det ännu viktigare att skapa en komponentstruktur som möjliggör så oberoende utveckling av komponenterna som möjligt än vid helt lokal utveckling. Konfigurationsstyrning Under denna punkt återfinner vi ändringshantering och då vem som godkänner ändringar. Skall också denna funktion vara distribuerad eller sköts den bäst centralt? Hur hanterar man ändringar som påverkar utvecklingen på flera platser? Hur och vem prioriterar vilka ändringar som skall göras och i vilken ordning? Redovisning av konfigurationsstatus Riskerar man att förlora överblicken om uppföljningen sker helt lokalt? Vem kan då ta beslut om omprioriteringar mellan arbetsuppgifter som utförs på olika platser? Hur får man en samlad bild av status är det samma sak som summan av delstatus, eller missar man något väsentligt då? Konfigurationsrevision Vid distribuerad utveckling kan man i större utsträckning se färdigställande av komponenter som leveranser och jämställa distribuerade grupper hanteringsmässigt med underleverantörer. Sådana leveranser, och därmed revisioner, kommer kanske att ske mycket oftare. Innebär det i så fall för mycket overhead och hur undviker man att allt integrationsarbete måste ske hos beställaren, dvs centralt? CM ur ledningsperspektiv påverkas alltså ur många synpunkter av att arbetet sker distribuerat och den arbetsgång och utvecklingsprocess man tillämpat måste säkert i många fall revideras. Utvecklingen sker ofta i steg och i en första anpassning kan man kanske ta fasta på den erfarenhet man har från hantering av underleverantörer. I takt med att den distribuerade utvecklingen blir en allt större och naturligare del av verksamheten

23 3.3 CM ur utvecklarperspektiv - verktygsstöd 23 och att man får mer erfarenhet kan man successivt anpassa CM-hanteringen. Flera företag har kommit en bit på denna väg och deras ansatser och erfarenheter, som redovisas i avsnitt 6, "Erfarenheter och tips kring nyckelområden", och avsnitt 10, "Intervjuer", kan tjäna som inspirationskälla och vägledning. 3.3 CM ur utvecklarperspektiv - verktygsstöd Vi har ovan beskrivit hur en utvecklingsstrategi konkretiseras i en plan för hur utveckling och ändringar av ett system hanteras och dokumenteras samt en procedur, en ordningsföljd för hur och när ändringar får utföras och integreras. Ur utvecklarens synpunkt kan mycket av detta arbete underlättas avsevärt med lämpliga verktyg för det dagliga arbetet. Den CM-relaterade funktionalitet som man kan önska sig är omfattande och blir inte mindre av att vi här också tittar på problemen i samband med distribuerad utveckling. I denna rapport fokuserar vi huvudsakligen på följande verktygsaspekter som vi uppfattar som de mest centrala i detta sammanhang: Versionshantering (Version Control) - möjligheten att lagra olika versioner och varianter av ett dokument för att senare kunna hämta och jämföra dem. Konfigurationer/Urval (Configurations/Selection) - funktionalitet för att skapa respektive välja ut samhörande versioner (eller grenar) av olika dokument. Synkronisering (Concurrency Control) - hanterar samtidig åtkomst från flera användare, dvs parallell utveckling, antingen genom att förhindra sådan, eller genom att stödja den. Dessa aspekter kommenteras utförligare nedan. Först skall vi dock summariskt beröra annan CM-relaterad funktionalitet som också kan vara aktuell för verktygsstöd, och där distribuerad utveckling kan spela roll, men som vi inte kommer att gå djupare in på i denna rapport. Några av aspekterna involverar en terminologi som vi återkommer till ofta varför vi presenterar den samlat här: Systemgenerering (Build) mekanismer för att hålla genererade filer aktuella, t ex vid kompilering och länkning, helst utan att generera om något i onödan. I en distribuerad utvecklingssituation är det möjligt att tänka sig att genereringsresultatet delas, men i många fall är det också rimligt att det underhålls vid varje plats där det behövs. Rapportering, status rapportering av aktuell status med listor över vilka filer som ändrats under viss tid, vem som ändrat, skillnader mellan produkter, etc. Detta är viktiga funktioner framför allt för att stödja överblick hos projektledningen. De är troligen ännu viktigare vid distribuerad utveckling men vi ser det trots detta inte som avgörande vid genomgång av modeller och verktyg.

24 24 3 Konfigurationsledning (CM) Processtöd verktyg som hjälper utvecklaren att följa den utvecklingsmodell och utföra de moment som den och CM-planen föreskriver. Värdet av automatiserade sådana verktyg kan tänkas vara än större i distribuerad utveckling om arbetsuppgifter kan flyttas mellan olika platser. Ändringshantering system som stöd för hanteringen av insamling av ändringsbegäran, t ex i samarbete med kundstöd ( Help-desk ), generering av felrapporter, konkreta ändringsbegäran, utförande av ändringarna, dokumentation av problemet och lösningen samt när den blir tillgänglig. Mycket av detta arbete sker redan idag distribuerat genom att man ofta skiljer mellan organisation för kundstöd ( Support ) och för utveckling. Distribuerad utveckling gör inte denna situation så mycket annorlunda även om ett integrerat verktygsstöd skulle kunna erbjuda ökad spårbarhet (problem-ändringsbegäran-ändringar). Produktdatahantering (PDM - Product Data Management) hantering av struktur på produkten, ingående komponenter, programvara, dokumentation. PDM hanterar i princip inte programvara då stödsystemen saknar funktionalitet för att t ex bygga. Detta är ett helt område i sig, men tas inte upp mer i denna rapport. Åtkomstkontroll (Sekretess) att förhindra otillbörlig åtkomst till information utan att detta försvårar normalt arbete. Detta är en högst relevant problemställning i en situation med distribuerad utveckling Versionshantering Möjligheten att lagra, återskapa och registrera den historiska utvecklingen av ett dokument, en fil, är en fundamental egenskap för ett CM-system. Varje stabil upplaga av en fils innehåll kallas en version. Versioner av en fil kan organiseras på olika sätt. När de organiseras i sekvens kallas de revisioner. De kan också organisieras som parallella spår vilka kallas grenar ( branch ). Grenar kan slås samman, ensas till en ny version ( merge ) som alltså har två eller flera föregångare. Grennamn: Release 2.3 Release 2.4 Main Merge Bug-fix 1 6 label Revisioner Bug-fix Temporära grenar Macintosh-gren Permanent grenar Figur 1 Grundläggande versionshantering. Versionerna (1,2,3,4,5) är revisioner i samma gren ( Main ). Version 2 har fått namnet Release 2.3, medan version 5 fått namnet Release 2.4. Bug-fix 1 resp 2 är två temporära grenar (med en respektive två revisioner) som ensats med ( merge ) tillbaka till Main. Exemplet illustrerar också en permanent gren med tre revisioner (9,10,11).