Distribuerad utveckling. och. Configuration Management

Storlek: px
Starta visningen från sidan:

Download "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: 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).

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

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

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning

Läs mer

Vägledning för krav på dokumenterad information enligt ISO 9001:2015

Vägledning för krav på dokumenterad information enligt ISO 9001:2015 Vägledning för krav på dokumenterad information enligt ISO 9001:2015 1 Orientering Två av de viktigaste målen vid revideringen av standarderna i ISO 9000-serien var att a) utveckla förenklade standarder

Läs mer

Kursöversikt Certifierad Mjukvarutestare

Kursöversikt Certifierad Mjukvarutestare Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15

Läs mer

Göteborgs universitet Intern miljörevision. Exempel på frågor vid platsbesök

Göteborgs universitet Intern miljörevision. Exempel på frågor vid platsbesök Göteborgs universitet 2007-06-26 Intern miljörevision Exempel på frågor vid platsbesök Nedan finns exempel på frågor som kan ställas vid platsbesök inom den interna miljörevisionen. Ytterligare följdfrågor

Läs mer

Förklarande text till revisionsrapport Sid 1 (5)

Förklarande text till revisionsrapport Sid 1 (5) Förklarande text till revisionsrapport Sid 1 (5) Kravelementen enligt standarden ISO 14001:2004 Kap 4 Krav på miljöledningssystem 4.1 Generella krav Organisationen skall upprätta, dokumentera, införa,

Läs mer

Processinriktning i ISO 9001:2015

Processinriktning i ISO 9001:2015 Processinriktning i ISO 9001:2015 Syftet med detta dokument Syftet med detta dokument är att förklara processinriktning i ISO 9001:2015. Processinriktning kan tillämpas på alla organisationer och alla

Läs mer

Har funnits nästan lika länge som datorerna. Manuell process, svarta tavlan Verktygsstöd kom tidigt redan i början på

Har funnits nästan lika länge som datorerna. Manuell process, svarta tavlan Verktygsstöd kom tidigt redan i början på Versionshantering och subversion Bara en liten ändring till Vad är versionshantering? Versionshantering låter dig arbeta med olika versioner av systemet Versionshantering är en säkerhetsmekanism som tillåter

Läs mer

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08 Formpipe Platina och kvalité Rasmus Staberg, Teknisk direktör, 2014-04-08 04 08 1 Formpipe Presentation Bakgrund Platina släpptes som första release år 2000. Fick pris för Best in show från Bill Gates

Läs mer

Checklista för utvärdering av miljöledningssystem enligt ISO 14001:2004

Checklista för utvärdering av miljöledningssystem enligt ISO 14001:2004 Checklista för utvärdering av miljöledningssystem enligt ISO 14001:2004 I checklistan gäller det att instämma med de påståenden som anges i listan för att vara säker på att verksamhetens miljöledningssystem

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

Kontrollhandbok - utföra offentlig livsmedelskontroll. FÖRDJUPNING HACCP-principerna

Kontrollhandbok - utföra offentlig livsmedelskontroll. FÖRDJUPNING HACCP-principerna Kontrollhandbok - utföra offentlig livsmedelskontroll FÖRDJUPNING HACCP-principerna De sju HACCP-principerna Här följer en genomgång av de sju HACCP-principerna som finns angivna i lagstiftningen 1. Alla

Läs mer

Region Skåne Granskning av IT-kontroller

Region Skåne Granskning av IT-kontroller Region Skåne Granskning av IT-kontroller Per Stomberg Niklas Westerlund Deloitte AB Januari 2016 2 Innehållsförteckning 1. Sammanfattning... 3 2. Inledning... 4 2.1 Bakgrund och syfte... 4 2.2 Revisionskriterier...

Läs mer

Planera genomförande

Planera genomförande Planera genomförande 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

Agilt arbetssätt i komplexa organisationer. Välkomna! Anna Picetti, IT-HUSET 2011-10-27. www.it-huset.se

Agilt arbetssätt i komplexa organisationer. Välkomna! Anna Picetti, IT-HUSET 2011-10-27. www.it-huset.se Agilt arbetssätt i komplexa organisationer Välkomna! Anna Picetti, IT-HUSET 2011-10-27 Ord från en företagsledare Ett bra genomförande är 90 procent av framgången och strategin 10, varav magkänslan är

Läs mer

Information Management made simple

Information Management made simple Information Management made simple Genom fullständigt stöd för dokument hantering tillsammans med inbyggd ärendehantering och nämndadministration erbjuds ett komplett informationsstöd som påtagligt underlättar

Läs mer

Utfärdat av: Utf datum: Dokument nr: Utgåva - Issue: Ange för och efternamn 2002-08-14 Ange Dokumentnummer 001

Utfärdat av: Utf datum: Dokument nr: Utgåva - Issue: Ange för och efternamn 2002-08-14 Ange Dokumentnummer 001 Projekt: Ange projektnamn Preliminär Utfärdat av: Utf datum: Dokument nr: Utgåva - Issue: Ange för och efternamn 2002-08-14 Ange Dokumentnummer 001 Status: ANGE PROJEKTNAMN PROJEKTSPECIFIKATION Ange projektnamn

Läs mer

Ramverk för projekt och uppdrag

Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 1 (9) Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 2 (9) BAKGRUND/MOTIV... 3 MÅL OCH SYFTE... 3 DEFINITIONER AV PROJEKT... 3 MODELL FÖR PROJEKTSTYRNING...

Läs mer

Dokument 1 till Kontrakt PROJEKTGENOMFÖRANDE

Dokument 1 till Kontrakt PROJEKTGENOMFÖRANDE Dokument 1 till Kontrakt 2011-04-20 Sid 1 (7) Dokument 1 till Kontrakt PROJEKTGENOMFÖRANDE Unicon 2011 Dokument 1 till Kontrakt 2011-04-20 Sid 2 (7) Innehåll: 1. PROJEKTLEDNING... 3 1.1. Allmänt... 3 1.2.

Läs mer

Revisionsrapport. Granskning av intern styrning och kontroll av informationssäkerheten vid Verket för högskoleservice 2010.

Revisionsrapport. Granskning av intern styrning och kontroll av informationssäkerheten vid Verket för högskoleservice 2010. Revisionsrapport Verket för högskoleservice Box 24070 104 50 Stockholm Datum Dnr 2011-03-08 32-2010-0738 Granskning av intern styrning och kontroll av informationssäkerheten vid Verket för högskoleservice

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

HSA Schemauppdateringsprocess. Version 1.2.1

HSA Schemauppdateringsprocess. Version 1.2.1 HSA Schemauppdateringsprocess Version 1.2.1 Innehåll Revisionshistorik... 2 1. Översikt schemauppdateringsprocess... 3 2. Planeringsfas... 3 2.1.1 Behovsanalys... 3 2.1.2 Interaktion med kravställare...

Läs mer

Fem steg för bästa utvecklingssamtalet

Fem steg för bästa utvecklingssamtalet Fem steg för bästa utvecklingssamtalet Hitta drivkraften, styrkan och nå målet! Gita Bolt 2013 Copyright: airyox AB Mångfaldigande av denna skrift, helt eller delvis, är enligt lagen om upphovsrättsskydd

Läs mer

Revisionsrapport. 1 Inledning. Revision av uppbördsprocessen Moms. Skatteverket 171 94 Solna. Datum Dnr 2012-02-03 32-2011-0544

Revisionsrapport. 1 Inledning. Revision av uppbördsprocessen Moms. Skatteverket 171 94 Solna. Datum Dnr 2012-02-03 32-2011-0544 Revisionsrapport Skatteverket 171 94 Solna Datum Dnr 2012-02-03 32-2011-0544 Revision av uppbördsprocessen Moms 1 Inledning Riksrevisionen har som ett led i den årliga revisionen av Skatteverket granskat

Läs mer

Programvara i säkerhetskritiska tillämpningar

Programvara i säkerhetskritiska tillämpningar Programvara i säkerhetskritiska tillämpningar Programvara får inte bidra till att person, egendom eller miljö skadas 2003-09-02 1 Systemsäkerhetsprocessen vid försvarsmakten materielupphandling beskrivs

Läs mer

Kvalitetsmanual. Baserat på System ISO 9001. Active Care Sverup AB

Kvalitetsmanual. Baserat på System ISO 9001. Active Care Sverup AB Kvalitetsmanual Baserat på System ISO 9001 Active Care Sverup AB Uggledalsvägen 47, 427 40 BILLDAL Tel 031-91 75 25 Fax 031-91 75 05 Org. nr. SE556388-8766 www.activecare.se info@activecare.se Sammandrag

Läs mer

Preliminär specifikation av projekt

Preliminär specifikation av projekt Preliminär specifikation av projekt Projektets namn: Infraröd Minneslåda (numera omdöpt till FastSync) Uppdragsgivare: Alex Olwal aolwal@cs.columbia.edu Deltagare: Johan Ullberg Nils

Läs mer

Samma krav gäller som för ISO 14001

Samma krav gäller som för ISO 14001 Förordning (2009:907) om miljöledning i statliga myndigheter Relaterat till motsvarande krav i ISO 14001 och EMAS De krav som ställs på miljöledningssystem enligt EMAS är samma som ingår i ISO 14001. Dessutom

Läs mer

Matriser för korrelation mellan ISO 9001:2008 och ISO 9001:2015

Matriser för korrelation mellan ISO 9001:2008 och ISO 9001:2015 Matriser för korrelation mellan ISO 9001:2008 och ISO 9001:2015 Detta dokument innehåller matriser för korrelation mellan ISO 9001:2008 och ISO 9001:2015 samt mellan ISO 9001:20015 och ISO 9001:2008. Dokumentet

Läs mer

IT governance i praktiken: Styrning och kontroll över ITriskerna. Fredrik Björck Transcendent Group för ADBJ 2006-01-31. Agenda

IT governance i praktiken: Styrning och kontroll över ITriskerna. Fredrik Björck Transcendent Group för ADBJ 2006-01-31. Agenda IT governance i praktiken: Styrning och kontroll över ITriskerna med ISO2700X Fredrik Björck Transcendent Group för ADBJ 2006-01-31 Agenda IT governance definierat IT governance i praktiken och infosäk

Läs mer

Ledningssystem för IT-tjänster

Ledningssystem för IT-tjänster Styrning och ledning av IT med stöd av internationella standarder Ledningssystem för IT-tjänster sixten.bjorklund@sipit.se 2013-11-05 Sip It AB, Sixten Björklund 1 Kort om Sixten Konsult i eget bolag Ledning

Läs mer

Projekt- och kvalitetsstyrning på Frontec

Projekt- och kvalitetsstyrning på Frontec Projekt- och kvalitetsstyrning på Frontec Detta dokument beskriver hur Frontec bedriver utvecklingsprojekt med kvalitetssäkring FSAB_LS020_Projekt och kvalitetsstyrning A.doc Sida 1(6) Frontec kan projekt

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

2014-2015 Alla rättigheter till materialet reserverade Easec

2014-2015 Alla rättigheter till materialet reserverade Easec 1 2 Innehåll Introduktion... 4 Standarder... 5 Översikt: Standarder... 6 1058.1-1987 IEEE Standard för Software Project Management Plans... 7 Ingående dokument... 8 Syfte och struktur... 9 ITIL... 10 ITIL

Läs mer

Bilaga. Särskilda villkor för Öppen källkod. Programvaror och tjänster 2014. Systemutveckling

Bilaga. Särskilda villkor för Öppen källkod. Programvaror och tjänster 2014. Systemutveckling Sid 1 (7) 2014-11-07 Dnr 96-36-2014 Bilaga Särskilda villkor för Öppen källkod Programvaror och tjänster 2014 Systemutveckling Sid 2 (7) Innehållsförteckning 1 Tillämplighet 2 2 Särskilt om kontraktshandlingar

Läs mer

Modell fo r ä ndringshäntering äv Sämbis gemensämmä tekniskä infrästruktur Version 1.0

Modell fo r ä ndringshäntering äv Sämbis gemensämmä tekniskä infrästruktur Version 1.0 Modell fo r ä ndringshäntering äv Sämbis gemensämmä tekniskä infrästruktur Version 1.0 Innehåll Revisionshistorik... 2 1. Inledning... 2 1.1. Syfte... 2 1.2. Omfattning och avgränsning... 2 2. Princip

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

VÄLKOMMEN Frukostmöte 2012-11-22

VÄLKOMMEN Frukostmöte 2012-11-22 VÄLKOMMEN Frukostmöte 2012-11-22 Kort om ramavtalen Kort om en metodik Offentlig sektors erkänt ledande konsult vid förändring och utveckling av verksamhet med hjälp av IT Oberoende konsultbolag Kombination

Läs mer

Riktlinjer för hantering av intressekonflikter

Riktlinjer för hantering av intressekonflikter Riktlinjer för hantering av intressekonflikter Styrelsen för Redeye AB ( Bolaget ) har mot bakgrund av 8 kap. 21 lagen (2007:528) om värdepappersmarknaden och 11 kap. Finansinspektionens föreskrifter (FFFS

Läs mer

EAs krav vid ackreditering av flexibel omfattning

EAs krav vid ackreditering av flexibel omfattning SWEDAC DOC 12:1 2012-05-10 Utgåva 1 Inofficiell översättning av EA 2/15 M:2008 EAs krav vid ackreditering av flexibel omfattning Swedac, Styrelsen för ackreditering och teknisk kontroll, Box 878, 501 15

Läs mer

Software Asset Management (SAM) Licenshantering i Göteborgs Stad

Software Asset Management (SAM) Licenshantering i Göteborgs Stad Software Asset Management (SAM) Licenshantering i Göteborgs Stad Vad är SAM? Software Asset Management beskriver alla de krav på infrastruktur och processer som krävs för en effektiv förvaltning, kontroll

Läs mer

Betyg och bedömning. Lokala kursplaner. Konsten att synliggöra kurskriterier för elever och för oss själva

Betyg och bedömning. Lokala kursplaner. Konsten att synliggöra kurskriterier för elever och för oss själva Betyg och bedömning Lokala kursplaner Konsten att synliggöra kurskriterier för elever och för oss själva Johan Dahlberg 2010 Att arbeta med bedömning och betygssättning så att en rättssäker och likvärdig

Läs mer

IT-Strategi 2004-10-12 1(7) IT-strategi 2005-01-14 KF 10/05

IT-Strategi 2004-10-12 1(7) IT-strategi 2005-01-14 KF 10/05 IT-Strategi 2004-10-12 1(7) IT-strategi 2005-01-14 KF 10/05 IT-Strategi 2004-10-12 2(7) Innehåll 1 Inledning...3 1.1 Bakgrund...3 2 Intention...3 3 Ledning och ansvar...4 4 Nuläge...5 5 Strategier och

Läs mer

360 Avtalshantering. Överblick, enkelhet och effektivitet i avtalshanteringen

360 Avtalshantering. Överblick, enkelhet och effektivitet i avtalshanteringen Överblick, enkelhet och effektivitet i avtalshanteringen 360 Avtalshantering håller organisationen uppdaterad och utgör beslutsunderlag när avtal ska ingås, övervakas eller omförhandlas. Utmaningarna är

Läs mer

Anslutningsprocess SNPAC - AM CRDB TM-20530037-0615-012-01-8. Capgemini 2005-10-23

Anslutningsprocess SNPAC - AM CRDB TM-20530037-0615-012-01-8. Capgemini 2005-10-23 2 / 12 Innehållsförteckning 1. Syfte med dokumentet... 4 2. Introduktion... 4 2.1 Bakgrund... 4 2.2 Kommunikation och information... 4 3. Beskrivning en för Direktanslutning... 5 3.1 Beställningsadministration...

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

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

SNPAC Swedish Number Portability Administrative Centre

SNPAC Swedish Number Portability Administrative Centre 1 (10) Innehållsförteckning 1. Syfte med dokumentet... 2 2. Introduktion... 2 2.1 Bakgrund... 2 2.2 Kommunikation och information... 2 3. Beskrivning Anslutningsprocessen för Direktanslutning... 3 3.1

Läs mer

FCAB KVALITETSSYSTEM. Projektledning och kvalitetssäkring

FCAB KVALITETSSYSTEM. Projektledning och kvalitetssäkring Projektledning och kvalitetssäkring KVALITETSSYSTEM Kvalitetssäkring ingår som en naturlig del i FC. AB:s arbetsmodell. FC. AB:s arbetsmodell är väl dokumenterad och används för alla delar av utvecklingskedjan.

Läs mer

Lathund Blanketthotell Komma igång

Lathund Blanketthotell Komma igång Lathund Blanketthotell Komma igång Introduktion Denna lathund innehåller lite samlade råd och tips för de som ska använda tjänster från NT Smartwork. (För de som redan börjat använda Blanketthotellet finns

Läs mer

Botkyrka Kommun. Revisionsrapport. Generella IT kontroller Aditro och HRM. Detaljerade observationer och rekommendationer.

Botkyrka Kommun. Revisionsrapport. Generella IT kontroller Aditro och HRM. Detaljerade observationer och rekommendationer. Botkyrka Kommun Revisionsrapport Generella IT kontroller Aditro och HRM Detaljerade observationer och rekommendationer Oktober 2015 Anders Hägg Fredrik Dreimanis Anna Lång Thomas Bauer Innehållsförteckning

Läs mer

Migration to the cloud: roadmap. PART 1: Möjligheter och hinder för att migrera till molnet

Migration to the cloud: roadmap. PART 1: Möjligheter och hinder för att migrera till molnet Migration to the cloud: roadmap PART 1: Möjligheter och hinder för att migrera till molnet PART 1 ÖVERSIKT 1. Varför migrera till molnet? 2. Möjligheter med migrering till molnet 3. Hinder för att migrera

Läs mer

HP ALM som stöd under implementationslivscykeln av standard applikationer Sarah Eriksson & Per Nordlander SAST

HP ALM som stöd under implementationslivscykeln av standard applikationer Sarah Eriksson & Per Nordlander SAST HP ALM som stöd under implementationslivscykeln av standard applikationer 2012-09-13 1 Vilka är vi? Sarah Eriksson, konsult på Connecta inom Enterprise Solutions. Sarah arbetar som testledare för standardapplikationer

Läs mer

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH F7 Agila metoder EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH 1 XP - Scrum - Kanban Agila metoder Vad innehåller SCRUM Hur skiljer sig XP och SCRUM KANBAN

Läs mer

Steget efter CAD Data Management. Per Ekholm

Steget efter CAD Data Management. Per Ekholm Steget efter CAD Data Management Per Ekholm Agenda Vilka processer/discipliner stöds i PDMLink Dokument management Configuration Management Change Management Project Management Hur utvärderar jag behovet?

Läs mer

Bilaga 1 Allmänna villkor för Socialnämnds anslutning till Sammansatt Bastjänst Ekonomiskt Bistånd (SSBTEK)

Bilaga 1 Allmänna villkor för Socialnämnds anslutning till Sammansatt Bastjänst Ekonomiskt Bistånd (SSBTEK) Bilaga 1 Allmänna villkor för Socialnämnds anslutning till Sammansatt Bastjänst Ekonomiskt Bistånd (SSBTEK) 1. Allmänt Dessa Allmänna villkor reglerar Socialnämndens anslutning till Sammansatt Bastjänst

Läs mer

STADSLEDNINGSKONTORET SOA SDK IT-AVDELNINGEN VERSION 2.1. Läs mig först. Stockholms stad SOA-plattform. Sida 1 (5)

STADSLEDNINGSKONTORET SOA SDK IT-AVDELNINGEN VERSION 2.1. Läs mig först. Stockholms stad SOA-plattform. Sida 1 (5) Läs mig först Stockholms stad SOA-plattform 1 (5) Innehållsförteckning 1 Beskrivning av SDK 3 1.1 Software Developer Kit för Utvecklare... 3 1.2 Support för... 3 1.3 Omfattning... 4 1.4 Versionshantering...

Läs mer

SOLLENTUNA FÖRFATTNINGSSAMLING 1

SOLLENTUNA FÖRFATTNINGSSAMLING 1 FÖRFATTNINGSSAMLING 1 IT-STRATEGI FÖR SOLLENTUNA KOMMUN Antagen av fullmäktige 2003-09-15, 109 Inledning Informationstekniken har utvecklats till en världsomspännande teknik som omfattar datorer, telefoni,

Läs mer

PROMARK WORKFORCE MANAGEMENT ProPC

PROMARK WORKFORCE MANAGEMENT ProPC är den mobila arbetsplatsen en Windowsbaserad terminal för alla typer av registreringar via dator eller surfplatta, både på företaget och för dem på språng. Imponerande kraftfull off-line funktionalitet.

Läs mer

Anmälan om. schablonmetoden, operativ risk

Anmälan om. schablonmetoden, operativ risk Anmälan om Februari 2007 schablonmetoden, operativ risk N Allmän information om anmälningsförfarandet Detta dokument innehåller Finansinspektionens krav på hur en anmälan om att använda schablonmetoden

Läs mer

Riktlinjer för IT i Lilla Edets kommun. 2. Syftet med IT i Lilla Edets kommun

Riktlinjer för IT i Lilla Edets kommun. 2. Syftet med IT i Lilla Edets kommun Datum Dnr Dpl 2009-09-10 2009/KS0203-1 005 Riktlinjer för IT i Lilla Edets kommun 1. Introduktion Det politiskt styrande dokumentet för IT-användning i Lilla Edets kommun är denna riktlinje, som fastställs

Läs mer

Säkerhetsbrister i kundplacerad utrustning

Säkerhetsbrister i kundplacerad utrustning BESLUT 1(11) Datum Vår referens Aktbilaga 2015-12-16 Dnr: 14-11014 20 Nätsäkerhetsavdelningen Peder Cristvall 08-6785529 peder.cristvall@pts.se Telenor Sverige AB Säkerhetsbrister i kundplacerad utrustning

Läs mer

Riskanalys för signaltekniska anläggningsprojekt

Riskanalys för signaltekniska anläggningsprojekt Gäller för Version Standard BV utan resultatenheter 1.0 BVS 1544.94006 Giltigt från Giltigt till Antal bilagor 2009-01-19 Diarienummer Ansvarig enhet Fastställd av F08-3369/SI10 Leverans Anläggning Björn

Läs mer

Bilaga 3 Säkerhet. Bilaga 3 Säkerhet. Dnr 93-25-09 Fasta och mobila operatörstjänster samt transmission -C

Bilaga 3 Säkerhet. Bilaga 3 Säkerhet. Dnr 93-25-09 Fasta och mobila operatörstjänster samt transmission -C Säkerhet Säkerhet 2 (14) Innehåll 1 Allmänt 3 2 Säkerhet 4 2.1 Administrativa säkerhetskrav 4 2.1.1 Basnivå för informationssäkerhet 4 2.1.2 Uppföljning och kontroll säkerhetsrevision 5 2.1.3 Säkerhets-

Läs mer

Granskning av bisysslor i Valdemarsviks kommun

Granskning av bisysslor i Valdemarsviks kommun Granskning av bisysslor i Valdemarsviks kommun Räkenskapsår 2013 Datum 1 augusti 2013 Till Kommunrevisionen i Valdemarsviks kommun Från R Wallin 1 Inledning På uppdrag av kommunrevisionen i Valdemarsvik

Läs mer

Revisionsrapport. Granskning av intern styrning och kontroll av informationssäkerheten vid Malmö Högskola 2011. Sammanfattning 2012-05-22 32-2011-0688

Revisionsrapport. Granskning av intern styrning och kontroll av informationssäkerheten vid Malmö Högskola 2011. Sammanfattning 2012-05-22 32-2011-0688 Revisionsrapport Malmö Högskola 205 06 Malmö Datum Dnr 2012-05-22 32-2011-0688 Granskning av intern styrning och kontroll av informationssäkerheten vid Malmö Högskola 2011 Riksrevisionen har som ett led

Läs mer

Göteborg Energi AB. Självdeklaration 2012 Verifiering av inköpsprocessen Utförd av Deloitte. 18 december 2012

Göteborg Energi AB. Självdeklaration 2012 Verifiering av inköpsprocessen Utförd av Deloitte. 18 december 2012 Göteborg Energi AB Självdeklaration 2012 Verifiering av inköpsprocessen Utförd av Deloitte 18 december 2012 1 Sammanfattning Med start hösten 2010 har Deloitte, Ernst & Young och PwC på uppdrag av Göteborgs

Läs mer

Projektplan, Cykelgarage

Projektplan, Cykelgarage Projektplan, Cykelgarage Johan Anderholm, (dt08ja5@student.lth.se) Jon Andersen (dt08ja8@student.lth.se) Marcus Carlberg (dt08mc4@student.lth.se) Simon Ekvy (dt08se2@student.lth.se) Stefan Johansson (dt08sj7@student.lth.se)

Läs mer

Sida 1 (av 12) Revision 1.18. Skall-krav

Sida 1 (av 12) Revision 1.18. Skall-krav 1 (av 12) I standarden SS-EN ISO 9000:2000 förekommer ordet skall 148 gånger. I 132 gånger används skall som ett krav. I till exempel 7.4.1 anges Inköpsinformationen skall specificera den produkt som skall

Läs mer

ATT DRIVA JÄMSTÄLLDHET

ATT DRIVA JÄMSTÄLLDHET ATT DRIVA JÄMSTÄLLDHET 10 trender om jämställdhetsarbete i Sverige 1. Prioritering Större i ord än handling En studie med 10 trender som visar tempen på jämställdhetsarbete i Sverige, kontrasterad mot

Läs mer

Övergripande granskning av ITverksamheten

Övergripande granskning av ITverksamheten Övergripande granskning av ITverksamheten Februari 2006 (1) 1. Inledning PricewaterhouseCoopers (PwC) har på uppdrag av kommunrevisionen i Borås Stad genomfört en övergripande granskning av Borås Stads

Läs mer

Slutrapport Central licenshantering

Slutrapport Central licenshantering Slutrapport Central licenshantering Författare: Ida Francke Datum: 2011-06-30 Innehåll Bakgrund... 2 Måluppfyllelse... 2 Kvarstående punkter... 3 Organisation... 4 Tidplan/Resursåtgång... 4 Tid... 4 Budget...

Läs mer

IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser

IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser Revisionsrapport IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser Landstinget i Jönköpings län Kerem Kocaer Johan Elmerhag Jean Odgaard September 2013 Innehållsförteckning

Läs mer

Datalagringsmetodik och arkitektur i Java. Projektdefinition. Projektdefinition. Björn Brenander. 7 maj 2001

Datalagringsmetodik och arkitektur i Java. Projektdefinition. Projektdefinition. Björn Brenander. 7 maj 2001 Datalagringsmetodik och arkitektur i Java Projektdefinition Dokumenttitel Projektdefinition Dokumentansvarig Dokumentförfattare Björn Brenander Dokumentnamn Projektdefinition.doc Version 16 Ref. nr. Skapades

Läs mer

Mejl och mobilpolicy

Mejl och mobilpolicy Mejl och mobilpolicy Tillgänglighet efter arbetstid blir allt vanligare och har många orsaker. Många tjänstemän har fått friare arbetstider och ges allt större möjlighet att utföra arbetsuppgifter på distans.

Läs mer

Scrum i praktiken Tillämpning inom Gripen demonstrator. Fredrik Lorentzon & Marcus Frejd 2010-11-11 SESAM

Scrum i praktiken Tillämpning inom Gripen demonstrator. Fredrik Lorentzon & Marcus Frejd 2010-11-11 SESAM Scrum i praktiken Tillämpning inom Gripen demonstrator Fredrik Lorentzon & Marcus Frejd 2010-11-11 SESAM Agenda Vilka är Fredrik och Marcus? Gripen demonstratorprogram i korthet Varför och hur införde

Läs mer

BILAGA E till Programvaruprojekt ÅTERSTÅENDE PROBLEM MultiPC v1.0. Innehållsförteckning

BILAGA E till Programvaruprojekt ÅTERSTÅENDE PROBLEM MultiPC v1.0. Innehållsförteckning ÅTERSTÅENDE PROBLEM MultiPC v1.0 Rev 7 1(7) BILAGA E till Programvaruprojekt ÅTERSTÅENDE PROBLEM MultiPC v1.0 Här listas problem som kan behöva hanteras i kommande inkrement. De prioriteras alltså ner

Läs mer

6. Att få mer gjort under en dag - Time Management

6. Att få mer gjort under en dag - Time Management 6. Att få mer gjort under en dag - Time Management Tiden är en unik och icke förnybar resurs. Den tid som gått får du inte igen. Du kommer inte att få mer tid, du har ett visst antal timmar till ett visst

Läs mer

KVALITETS- OCH KONTROLLBESTÄMMELSER FÖR ELEKTRISK UTRUSTNING

KVALITETS- OCH KONTROLLBESTÄMMELSER FÖR ELEKTRISK UTRUSTNING Sid 1 (5) KVALITETS- OCH KONTROLLBESTÄMMELSER FÖR ELEKTRISK UTRUSTNING Rubrik Dokument Allmänna kvalitets- och kontrollbestämmelser KBE 100-2 Utgåva 3 (S) Innehåll 1 KRAVNIVÅINDELNING... 2 2 KVALITETSSÄKRINGSSYSTEM...

Läs mer

IT-generella kontroller i Agresso, skattekontosystemet, Moms AG och Tina

IT-generella kontroller i Agresso, skattekontosystemet, Moms AG och Tina 1 IT-generella kontroller i Agresso, skattekontosystemet, Moms AG och Tina Riksrevisionen har som ett led i den årliga revisionen av Skatteverket granskat IT-generella kontroller i ekonomisystemet Agresso,

Läs mer

Hur kan man uppnå tillståndet där Lean/Verksamhetsutveckling är en naturlig del av tillvaron?

Hur kan man uppnå tillståndet där Lean/Verksamhetsutveckling är en naturlig del av tillvaron? Hur kan man uppnå tillståndet där Lean/Verksamhetsutveckling är en naturlig del av tillvaron? Av Ronny Brandqvist Sida 1 av 19 Lean är INTE ett statiskt tillstånd Sida 2 av 19 Hur kan det se ut? Attityder,

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

PROJEKTLEDNING inom produktutveckling. Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10

PROJEKTLEDNING inom produktutveckling. Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10 PROJEKTLEDNING inom produktutveckling Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10 Innehållsförteckning Inledning... 3 Projektarbete... 4 Projektledning & Ledarskap...

Läs mer

Riktlinjer för internkontroll i Kalix kommun

Riktlinjer för internkontroll i Kalix kommun Riktlinjer för internkontroll i Kalix kommun Antaget av kommunfullmäktige 2012-11-26--27, 182 Innehållsförteckning Riktlinjer för internkontroll i Kalix kommun...1 Inledning...1 Internkontroll...1 Organisation

Läs mer

VERVA. Fujitsu Services Kenneth Landérus F

VERVA. Fujitsu Services Kenneth Landérus F VERVA Fujitsu Services Kenneth Landérus F Fujitsu Services 2008 Fujitsus erbjudande produkter Volymlicensiering på 40 programtillverkares produkter 2 Fujitsu Services 2008 2008-01-28 Verva Programvaror

Läs mer

Examensarbeten, litteraturstudier och teoretisk geoekologi / geografi. Gemensamma riktlinjer för hela institutionen

Examensarbeten, litteraturstudier och teoretisk geoekologi / geografi. Gemensamma riktlinjer för hela institutionen Examensarbeten, litteraturstudier och teoretisk geoekologi / geografi Gemensamma riktlinjer för hela institutionen Innehåll för examensarbeten Under kursen utför och redovisar studenterna en vetenskaplig

Läs mer

Bilaga. Särskilda villkor för Molntjänst. Programvaror och tjänster 2014. Systemutveckling

Bilaga. Särskilda villkor för Molntjänst. Programvaror och tjänster 2014. Systemutveckling Sid 1 (7) 2014-11-07 Dnr 96-36-2014 Bilaga Särskilda villkor för Molntjänst Programvaror och tjänster 2014 Systemutveckling Sid 2 (7) Innehållsförteckning 1 Tillämplighet 2 2 Särskilt om kontraktshandlingar

Läs mer

Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet

Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet Innehållsförteckning 1. Generell informationssäkerhet... 4 1.1. Styrande dokumentation... 4 1.2. Organisation... 4 Incidenthantering...

Läs mer

Rammeverk: Rutin för intern uppföljning av korrigeringar i levererad statistik felrapportering

Rammeverk: Rutin för intern uppföljning av korrigeringar i levererad statistik felrapportering STATISTISKA CENTRALBYRÅN RAPPORT 1(5) Rammeverk: Rutin för intern uppföljning av korrigeringar i levererad statistik felrapportering E-post: mats.bergdahl@scb.se Statistiska centralbyrån, Processavdelningen

Läs mer

Makes quality Happen NÖJDA KUNDER EFFEKTIVITET

Makes quality Happen NÖJDA KUNDER EFFEKTIVITET Makes IT happen Idnet grundades 1991 och har på den tiden gått från att vara en teknikleverantör till att bli en expert på IT-logistiklösningar för varuflöden i både butik-, lager- och transportsektorn.

Läs mer

Praktikrapport. Sofia Larsson MKVA12, HT12

Praktikrapport. Sofia Larsson MKVA12, HT12 Praktikrapport Facetime Media är en byrå belägen i Lund som hjälper företag att marknadsföra sig via sociala medier. I nuläget är det främst Facebook som är aktuellt men tanken är att företaget i framtiden

Läs mer

IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser

IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser Revisionsrapport IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser Landstinget i Östergötland Kerem Kocaer Magnus Olson-Sjölander Björn Johrén IT-specialister Eva Andlert

Läs mer

AffärsCoaching i privata och offentliga organisationer. En praktisk handledning.

AffärsCoaching i privata och offentliga organisationer. En praktisk handledning. Gunnela Westlander, bokanmälan Gunnar Kihlblom: AffärsCoaching i privata och offentliga organisationer. En praktisk handledning. Värmdö: Solid Affärs Coaching. ISBN 978-91-633-8657-2 Coaching är en metod

Läs mer

ALLMÄNNA VILLKOR APPMANAGER CMS 1.0. MOBILAPPEN ORANGE. APPSALES SWEDEN AB

ALLMÄNNA VILLKOR APPMANAGER CMS 1.0. MOBILAPPEN ORANGE. APPSALES SWEDEN AB ALLMÄNNA VILLKOR APPMANAGER CMS 1.0. MOBILAPPEN ORANGE. APPSALES SWEDEN AB Appsales Allmänna villkor för Appsales AppManager CMS Mobila Applikationer skapade i verktygen AppManager CMS 1.0 AppManager CMS.

Läs mer

Operatörer och användargränssnitt vid processtyrning

Operatörer och användargränssnitt vid processtyrning Operatörer och användargränssnitt vid processtyrning Normativa och beskrivande analyser Uppsala universitet @ 2003 Anders Jansson Sammanfattning kap. 1 Sociotekniska system Många olika grupper av användare

Läs mer

Lyckade projekt - finns det?

Lyckade projekt - finns det? Lyckade projekt - finns det? Maria Lindqvist Björkman Enea Business Software Enea Business Software 2002 Sida 1 Agenda Förväntningar kund & leverantör Statistik om projekt Framgångsfaktorer Exempel på

Läs mer

Stockholm den 19 oktober 2015

Stockholm den 19 oktober 2015 R-2015/1084 Stockholm den 19 oktober 2015 Till FAR Sveriges advokatsamfund har genom remiss den 2 juli 2015 beretts tillfälle att avge yttrande över Nordiska Revisorsförbundets förslag till Nordisk standard

Läs mer

Repetition L1-L4 Övergripande designprocessen

Repetition L1-L4 Övergripande designprocessen Repetition L1-L4 Övergripande designprocessen 1. Definiera behov/kundnytta 2. Planera hur problemet skall lösas 3. Förstå problemet genom att ta fram kravspec 4. Generera många lösningsförslag (koncept)

Läs mer

TeamEngine STYRELSEPLATS DELA STYRELSEMATERIALET SMARTARE OCH SMIDIGARE

TeamEngine STYRELSEPLATS DELA STYRELSEMATERIALET SMARTARE OCH SMIDIGARE TeamEngine STYRELSEPLATS DELA STYRELSEMATERIALET SMARTARE OCH SMIDIGARE DET HÄR ÄR TEAMENGINE DISTRIBUERA STYRELSEMATERIALET ENKLARE Med TeamEngine styrelseplats får du och övriga styrelsemedlemmar en

Läs mer