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).

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

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

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

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

Ö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

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

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

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

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

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

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

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

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

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

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

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

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

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

Läs mer

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

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

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

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

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

Inledning Syfte Metod Avgränsningar Om Wahlquist Teori Varför uppgradera? Leverantören vill det Implementera helt nya funktioner (revolutionärt)

Inledning Syfte Metod Avgränsningar Om Wahlquist Teori Varför uppgradera? Leverantören vill det Implementera helt nya funktioner (revolutionärt) Inledning Syfte Metod Avgränsningar Om Wahlquist Wahlquist Verkstäder grundades 1945 och har idag växt till en storlek av 150 anställda på tre platser: Linköping, Ödeshög och Tallinn. De har en hög teknisk

Läs mer

Curriculum Vitae - Anders Persson. Anders Persson

Curriculum Vitae - Anders Persson. Anders Persson Anders Persson Anders har en civilingenjörsexamen i elektroteknik. Han har 30 års erfarenhet av mjukvaruutveckling, främst från Telekommunikation och CAD / CAM industrin. Anders är en erfaren verksamhetsutvecklare

Läs mer

Processbeskrivning Systemutveckling

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

Läs mer

Dokumenttyp: Projekt: Projektnummer: Utfärdat av: Utf datum: Godkänt av : Godk datum: PROJEKTBESKRIVNING... 1

Dokumenttyp: Projekt: Projektnummer: Utfärdat av: Utf datum: Godkänt av : Godk datum: PROJEKTBESKRIVNING... 1 Dokument nr: Version: Status: Sida: 1.00 Prel Utgåva (1)9 Dokumenttyp: Projekt: Projektnummer: Projektbeskrivning Dokumentbeskrivning: Underlag för beslut om stimulansmedel Mobilitet Mobila tjänster Utfärdat

Läs mer

Policy och riktlinjer för E-förvaltning och IT-användning inom Falköpings kommun 2012 2014

Policy och riktlinjer för E-förvaltning och IT-användning inom Falköpings kommun 2012 2014 Policy och riktlinjer för E-förvaltning och IT-användning inom Falköpings kommun 2012 2014 Ledning och styrning av IT i kommunen Kommunen har sedan många år en central IT-avdelning med ansvar för drift

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

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

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

De t Mobil Tim gl as e t

De t Mobil Tim gl as e t Det Mobila Timglaset Det mobila timglaset Det mobila timglaset är framtaget för att öka förståelsen för hur en organisation påverkas och kan höja sin effektivitet genom att införa mobil ärendehantering.

Läs mer

PIMM PROFECTO INFRASTRUCTURE MANAGEMENT MODEL ETT WHITEPAPER OM PIMM

PIMM PROFECTO INFRASTRUCTURE MANAGEMENT MODEL ETT WHITEPAPER OM PIMM PIMM PROFECTO INFRASTRUCTURE MANAGEMENT MODEL ETT WHITEPAPER OM PIMM PROFECTO SERVICE MANAGEMENT AB 2014 Inledning... 3 Grundstenarna i IT Service Management... 3 Samverkan och styrning... 4 Modellens

Läs mer

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

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

Läs mer

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

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

Läs mer

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

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

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

Helhetsåtagande underhåll och drift

Helhetsåtagande underhåll och drift SID (0) Bilaga b Helhetsåtagande underhåll och drift Förfrågningsunderlag Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt genomförande inom Skolplattform Stockholm Box 09, 0 Stockholm.

Läs mer

ISO 20 000 med kundfokus

ISO 20 000 med kundfokus ISO 20 000 med kundfokus Karlstad Peter Olsson Service Design Manager 2011-11-15 IT-enheten Koncerngemensam centraliserad IT, 62 anställda Intäktsfinansierad enhet 115 miljoner SEK i omsättning Våra kunder:

Läs mer

Configuration Management Vägen till ordning och reda med rätt stöd! 2010-03-23. Greger.Ohlsson@bita.eu

Configuration Management Vägen till ordning och reda med rätt stöd! 2010-03-23. Greger.Ohlsson@bita.eu Configuration Management Vägen till ordning och reda med rätt stöd! 2010-03-23 Greger.Ohlsson@bita.eu BiTA Service Management Tjänsteområden inom utbildning och konsultation: IT-styrning IT-kvalitet IT-effektivitet

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

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

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

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

Läs mer

Riktlinjer för Försäkringskassans begreppskatalog

Riktlinjer för Försäkringskassans begreppskatalog Försäkringsprocesser RIKTLINJER 2010-01-15 Ändringsdatum Serienummer Version 2010:01 1.0 1 (10) + Riktlinjer för Försäkringskassans begreppskatalog Försäkringsprocesser RIKTLINJER 2010-01-15 Ändringsdatum

Läs mer

Kursprogram, ETS032 Programvaruutveckling för stora system (PUSS), 7,5 hp

Kursprogram, ETS032 Programvaruutveckling för stora system (PUSS), 7,5 hp ursprogram, S032 Programvaruutveckling för stora system (PUSS), 7,5 hp Version 1.0 Christin Lindholm Läsåret 2012/2013 Våren 2013 1. Inledning Syftet med kursen är att ge grundläggande kunskaper i utvecklingsprocesser,

Läs mer

Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014

Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014 Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014 Kurswebb: www.creativerooms.se/edu, välj Gränssnittsdesign eller Webbutveckling 1 Lärare: Aino-Maria Kumpulainen, aino-maria.kumpulainen@it-gymnasiet.se

Läs mer

Övergripande riktlinjer för IS/IT-verksamheten

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

Läs mer

IT-strategi-Danderyds kommun 2010-2014

IT-strategi-Danderyds kommun 2010-2014 IT-strategi-Danderyds kommun 2010-2014 Beslutsinstans: Kommunfullmäktige Beslutsdatum: 2010-09-27 Giltighetstid: 2010-09-27 t o m 2014-12-31 Ansvarig nämnd: Kommunstyrelsen Diarienummer: KS 2010/0095 IT-strategi

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

RIKTLINJER. Riktlinjer för styrning av IT-verksamhet

RIKTLINJER. Riktlinjer för styrning av IT-verksamhet RIKTLINJER Riktlinjer för styrning av IT-verksamhet RIKTLINJER 2 Riktlinjer för styrning av IT-verksamhet. 1 Inledning Håbo kommuns övergripande styrdokument inom IT är IT-policy för Håbo kommun. Riktlinjer

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

K V A L I T E T S S Y S T E M

K V A L I T E T S S Y S T E M Personalhandbok 1/11 100 037 05 2013-12-10/JJ Roland Holmgren K V A L I T E T S S Y S T E M Personalhandbok 2/12 INNEHÅLLSFÖRTECKNING 4.0 INLEDNING 3 4.1 FÖRETAGSLEDNINGENS ANSVAR 3 4.1.1 Kvalitetspolicy

Läs mer

Hantering av IT-risker

Hantering av IT-risker Hantering av IT-risker Landstinget i Östergötland Revisionsrapport Januari 2011 Jon Arwidson Magnus Olson-Sjölander Fredrik Eriksson Eva Andlert Certifierad kommunal revisor 1 av 10 Innehållsförteckning

Läs mer

Aktiviteter vid avtalets upphörande

Aktiviteter vid avtalets upphörande SID 1 (10) Bilaga 4h Aktiviteter vid avtalets upphörande Förfrågningsunderlag Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt genomförande inom Skolplattform Stockholm Box 22049, 104

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

Novi Net handelsbolag. Produkter och tjänster

Novi Net handelsbolag. Produkter och tjänster Novi Net handelsbolag Produkter och tjänster 25 november 2008 Sammanfattning Dokumentet innehåller prisuppgifter och information om tjänster och produkter levererade av Novi Net handelsbolag. Samtliga

Läs mer

Mobiltjänster. Vi kan smartphones. den nya mobiltelefonin. www.dustin.se. Telefon: 08-553 44 000 E-mail: info@dustin.se

Mobiltjänster. Vi kan smartphones. den nya mobiltelefonin. www.dustin.se. Telefon: 08-553 44 000 E-mail: info@dustin.se Mobiltjänster Vi kan smartphones Skaffa kontroll över den nya mobiltelefonin UTMANINGARNA Smartphone-revolutionen skapar nya utmaningar för IT-avdelningen De traditionella mobiltelefonerna är snart ett

Läs mer

WEBBTEKNIK. Ämnets syfte

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

Läs mer

WEBBTEKNIK. Ämnets syfte

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

Läs mer

Inga krav utöver ISO 14001

Inga krav utöver 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 utgår från kraven i ISO 14001. Dessutom

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

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

Projekt som ledningsutmaning. Läran om projektledning (1) Läran om projektledning (2) Anna Jerbrant

Projekt som ledningsutmaning. Läran om projektledning (1) Läran om projektledning (2) Anna Jerbrant Projekt som ledningsutmaning Läran om projektledning (1) 1942-45: Manhattanprojektet (USA). 2 miljarder dollar i omsättning, som mest 120.000 anställda. Målstyrning, parallella aktiviteter. 1950-talet:

Läs mer

360 Infrastruktur - 360 v.4.1 & SharePoint 2010. Magnus Larsson, Software Innovation

360 Infrastruktur - 360 v.4.1 & SharePoint 2010. Magnus Larsson, Software Innovation 360 Infrastruktur - 360 v.4.1 & SharePoint 2010 Magnus Larsson, Software Innovation Agenda 360 Grundinstallation 360 Avancerad installation 360 & Microsoft OneNote 360 Features installation 360 Grundinstallation

Läs mer

Distribuerade affärssystem

Distribuerade affärssystem Distribuerade affärssystem Kursens mål Bygga upp, strukturera och programmera distribuerade system med en flerskiktsarkitektur Beskriva och förklara teorier och uttryck som används inom affärskritiska

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

Molntjänster -- vad är molnet?

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

Läs mer

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

Bibliotekarien som intern konsult - erfarenheter från omvärldsbevakning i kommun och företag.

Bibliotekarien som intern konsult - erfarenheter från omvärldsbevakning i kommun och företag. Katarina Kristoffersson & Bibliotekarien som intern konsult - erfarenheter från omvärldsbevakning i kommun och företag. Paper presenterat vid konferensen 11-12 oktober 2006 i Borås Om föredragshållarna

Läs mer

Produktinformation viktigare än programvara?!

Produktinformation viktigare än programvara?! Produktinformation viktigare än programvara?! Standarden ISO 10303-239 PLCS gör g r det möjligt m att skapa en helhetsbild över den information som beskriver de krav du ställer påp din produkt, den resulterande

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

Inköp av licenser för ny IT-infrastruktur i Luleå kommun

Inköp av licenser för ny IT-infrastruktur i Luleå kommun Kommunstyrelsen 2012-04-16 89 221 Arbets- och personalutskottet 2012-03-12 65 142 Dnr 12.122-01 aprilks10 Inköp av licenser för ny IT-infrastruktur i Luleå kommun Bilaga: Specifikation inköp licenser Ärendebeskrivning

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

GRAFISK PRODUKTION. Ämnets syfte

GRAFISK PRODUKTION. Ämnets syfte GRAFISK PRODUKTION Ämnet behandlar den grafiska processen, hur en grafisk produkt utvecklas från idé till färdig produkt och de arbetsflöden processen bygger på. Det behandlar även betydelsen av samarbete

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

eklient Livscykelplaner i Samverkan Livscykelplaner eklient 1.0

eklient Livscykelplaner i Samverkan Livscykelplaner eklient 1.0 er i Samverkan 1 Revisionshistorik Datum Version Förändring 2014-04-25 0.96 Windows 7 SP1 som sekundärt OS från 1 okt 2015 2014-09-27 0.97 Windows 8 med updates primärt OS från 1 okt 2015, Windows 9 för

Läs mer

The Rational IT Model EN ENKLARE VÄG TILL IT SERVICE MANAGEMENT

The Rational IT Model EN ENKLARE VÄG TILL IT SERVICE MANAGEMENT The Rational IT Model EN ENKLARE VÄG TILL IT SERVICE MANAGEMENT ITIL is a registered trade mark of AXELOS Limited. Bakgrund till modellen... 3 Beskrivning av modellen... 4 Modellens uppbyggnad... 5 Faser...

Läs mer

Metoder och verktyg för funktionssäkerhet

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

Läs mer

Plattform as a Service, leverantör tillhandahåller plattformen, jag tillhandahåller applikation och ansvarar för denna.

Plattform as a Service, leverantör tillhandahåller plattformen, jag tillhandahåller applikation och ansvarar för denna. Modul 1: Molntjänst Publikt moln Privat moln Hybrid moln IaaS PaaS SaaS DaaS DaaS SLA Infrastructure as a Service, leverantör tillhandahåller infrastrukturen, jag tillhandahåller virtuella maskiner eller

Läs mer

PROJEKT ALBYLEN. Datum: 25 mars 2011. AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson

PROJEKT ALBYLEN. Datum: 25 mars 2011. AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson PROJEKT ALBYLEN Datum: 25 mars 2011 AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson 0 Sammanfattning: Föreningen Albylen som bedriver aktivitets- och friskvårdscentrum

Läs mer

Inbjudan till dialog avseende drift och kundstöd

Inbjudan till dialog avseende drift och kundstöd samhällsskydd och beredskap 1 (5) Myndigheten för samhällsskydd och beredskap 651 81 KARLSTAD Telefonväxel: 0771-240 240 E-post: registrator@msb.se Inbjudan till dialog avseende drift och kundstöd Inledning

Läs mer

Spetskompetens inom systemintegration, SOA och systemutveckling

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

Läs mer

Processbeskrivning Test

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

Läs mer

Intern styrning och kontroll i Riksbanken 2013

Intern styrning och kontroll i Riksbanken 2013 Rapport ISK 2013 DATUM: 201-01-21 AVDELNING: STA/RIE HANDLÄGGARE: Urban Örtberg HANTERINGSKLASS B E G R Ä N S A D SVERIGES RIKSBANK SE-103 37 Stockholm (Brunkebergstorg 11) Tel +6 8 787 00 00 Fax +6 8

Läs mer

Kärcher Fleet. Fokusera på att nå skinande resultat. Vi sammanfattar de åt dig.

Kärcher Fleet. Fokusera på att nå skinande resultat. Vi sammanfattar de åt dig. Kärcher Fleet Fokusera på att nå skinande resultat. Vi sammanfattar de åt dig. Ökat perspektiv för större framgång. Från den globala marknadsledaren inom rengöringsteknik kommer Kärcher Fleet - det innovativa

Läs mer

Manuell SMARTCD.G2 02.2015

Manuell SMARTCD.G2 02.2015 02.2015 2 / 14 1 Avsedd användning... 3 2 Säkerhetsanvisningar... 4 3 Ingår i leveransen... 5 4 Anslutning till en dator/bärbar dator... 6 5 Ladda batterierna... 7 6 Driftsättning... 8 7 Konfigurering

Läs mer

Innehåll Molntjänster... 4 Vad är detta?... 5 Cirkeln sluts... 6 The Cloud... 7 The Cloud (forts.)... 8 Definition av molntjänster...

Innehåll Molntjänster... 4 Vad är detta?... 5 Cirkeln sluts... 6 The Cloud... 7 The Cloud (forts.)... 8 Definition av molntjänster... 1 2 Innehåll Molntjänster... 4 Vad är detta?... 5 Cirkeln sluts... 6 The Cloud... 7 The Cloud (forts.)... 8 Definition av molntjänster... 9 Definition av molntjänster (forts.)... 11 Tjänster... 12 Skikt

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

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

Om kompetens och lärande

Om kompetens och lärande Om kompetens och lärande Vi bär på mycket mer kunskap än vi tror och kan så mycket mer än vi anar! När som helst i livet har du nytta och glädje av att bli medveten om delarna i din kompetens. Du funderar

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

Korsreferenslista, bilaga till VoB Syds kvalitetshandbok (innehåller uteslutningar). Dokumenterat i VoBs kvalitetssäkring:

Korsreferenslista, bilaga till VoB Syds kvalitetshandbok (innehåller uteslutningar). Dokumenterat i VoBs kvalitetssäkring: 1/5 Korsreferenslista, bilaga till VoB Syds kvalitetshandbok (innehåller uteslutningar). SS-EN ISO 9001 VoB Syd ABs kvalitetssäkring Krav i ISO 9001 0.2 Processorientering a. förstå och uppfylla krav b.

Läs mer

Vid avrop kan krav komma att ställas som är relaterade till arbetsmiljö till exempel ljud, ljus, ergonomi, strålning m.m.

Vid avrop kan krav komma att ställas som är relaterade till arbetsmiljö till exempel ljud, ljus, ergonomi, strålning m.m. 1 Kravkatalog Följande lista av krav kan avropande kund komma att tillämpa vid avrop vid förnyad konkurrensutsättning utöver de krav som tillämpas i denna upphandling. Tillämpningen kan ske både som obligatoriska

Läs mer

EBITS 2010-02-15 Arbetsgruppen för Energibranschens Reviderad 2010-02-17 Informationssäkerhet

EBITS 2010-02-15 Arbetsgruppen för Energibranschens Reviderad 2010-02-17 Informationssäkerhet 2010-02-15 Arbetsgruppen för Energibranschens Reviderad 2010-02-17 Informationssäkerhet IT SOM TJÄNST - MOLNTJÄNSTER Användning av internetbaserade IT-tjänster tillhandahållna av extern leverantör Syfte

Läs mer

Revisionsnämnden beslutade den 8 april 2013 att överlämna granskningen av internkontrollplaner till kommunstyrelsen.

Revisionsnämnden beslutade den 8 april 2013 att överlämna granskningen av internkontrollplaner till kommunstyrelsen. Kommunens revisorer 2013-04-08 GRANSKNING AV INTERNKONTROLLPLANER I HÄRRYDA KOMMUN Revisionsnämnden beslutade den 8 april 2013 att överlämna granskningen av internkontrollplaner till kommunstyrelsen. Rapporten

Läs mer

KVALITETS- MANUAL. Ansvarig: Jonas Danielsson. Senast reviderad: Kvalitetsmanual: 2006-10-01 Kvalitetssystemets dokumentation: 2006-09-30

KVALITETS- MANUAL. Ansvarig: Jonas Danielsson. Senast reviderad: Kvalitetsmanual: 2006-10-01 Kvalitetssystemets dokumentation: 2006-09-30 KVALITETS- MANUAL Ansvarig: Jonas Danielsson Senast reviderad: Kvalitetsmanual: 2006-10-01 Kvalitetssystemets dokumentation: 2006-09-30 B2B IT-Partner AB Box 1018, Svetsarvägen 8, 171 21 Solna Telefon

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

ibis Presentation Personalkonferensen 4-6/11 2013

ibis Presentation Personalkonferensen 4-6/11 2013 ibis Presentation Personalkonferensen 4-6/11 2013 Program Bakgrund och framtid Teknisk genomgång Tidsplan Utbildningsstrategi Support IDA-data Skillnader IDA ibis Olika arbetssätt Inställningar och egenskaper

Läs mer

Projekt intranät Office 365 av Per Ekstedt

Projekt intranät Office 365 av Per Ekstedt Projekt intranät Office 365 av Per Ekstedt 1 BESKRIVNING AV UTFÖRANDE Uppdraget planeras att genomföras med ett agilt arbetssätt samt best practice från Microsoft gällande SharePoint online. Uppdraget

Läs mer

Innehåll i detta dokument

Innehåll i detta dokument Läs igenom hela dokumentet innan du startar. Kopiera över allt på CD-skivan till din hårddisk. Din dator kommer behöva startas om en gång vid installationen av CodeSys. Du måste ha rättigheter att installera

Läs mer