Dokument: Arbetsmodell Ladok3 Version 1.0 Författare Sida 1 av 14 Bo Sehlberg Förberedelse av realiseringsfas Datum 2012-09-06 PM arbetsmodell för Ladok3 1 Inledning... 2 2 Organisation... 2 2.1 Roller... 3 2.1.1 Produktägare... 3 2.1.2 Verksamhetsteam... 3 2.1.3 Referensgrupper... 5 2.1.4 Lösningsansvarig... 5 2.1.5 Migreringsansvarig... 5 2.1.6 Projektteam... 6 2.1.7 Utvecklingsstöd... 6 2.1.8 ScrumMaster... 8 2.1.9 Scrum-team... 8 3 Artefakter... 9 3.1 Product Backlog... 9 3.2 Sprint Backlog... 9 3.3 Dokumentation... 9 3.4 Teman... 9 4 Produktionsmodell... 9 4.1 Utvecklingsprocessen...10 4.1.1 Bearbetning av Product Backlog...11 4.1.2 Sprintplanering...11 4.1.3 Design...12 4.1.4 Daglig Scrum...12 4.1.5 Sprint Review...12 4.1.6 Sprint Återblick...12 4.2 Leveranser och miljöer...12 5 Referenser...14
Sida 2 av 14 1 Inledning Dokumentet beskriver först projektets organisation med fokus på projektets lösnings- och migreringsdel. Därefter beskrivs de olika rollerna i denna del av projektet. Slutligen beskrivs de olika delarna i produktionsmodellen övergripande, vilket också innefattar utvecklingsprocessen och leveranshanteringen med utveckling-, test- och driftsmiljöer och de leveranser som behövs mellan miljöerna. Arbetsmodellen baseras på agil utveckling och ska drivas enligt Scrum. Utvecklingen kommer att baseras på domändriven design (DDD), testdriven utveckling (TDD) och beteendedriven utveckling (BDD). För mer information kring detta och övrigt kring projektets utvecklingsmetodik se ref [1]. 2 Organisation Nedanstående figur beskriver översiktligt de olika huvudgrupperna i projektets organisation. Dessa huvudgrupper består av en eller flera roller, som beskrivs i följande kapitel. Detta dokument beskriver de rollerna i inte de olika rollerna i den övre delen (projektledning). Figur 1 Övergripande organisation för Ladok3
Sida 3 av 14 2.1 Roller 2.1.1 Produktägare Produktägarrollen delas mellan två personer i Ladok3-projektet, dels med tanke på produktens omfattning, men även på grund av den distribuerade organisationen och de behov av lokal förankring som kan behövas i olika situationer. Produktägarens viktigaste åtaganden är följande: Har en klar vision av produkten och definierar produktens huvuddrag. Driver projektet från en verksamhetssynvinkel. Ska godkänna/acceptera produkten vid varje avslutad Sprint. Ansvarar för att Teamet arbetar med de viktigaste objekten i Product Backlog. Ansvarar för att alla oklarheter är utredda för de aktiviteter som ska tas om hand av kommande Sprint. Stöder Teamet genom att ge dem all nödvändig information. Ska kontinuerligt prioritera funktionaliteten i Product Backlog efter verksamhetsvärde. Beslutar om release-datum och innehåll. Har möjlighet att i undantagsfall stoppa en Sprint, om någon drastisk förändring krävs. Deltar i Sprint Planering och Review. Produktägaren har till sitt förfogande ett Verksamhetsteam som stöd för att att utreda eventuella oklarheter i Product Backlog att tillhandahålla områdesproduktägare till projektteam att tillhandahålla domänexpert till projektteam att tillhandahålla verksamhetstestare till Scrum-team Förutom Verksamhetsteamet, har produktägaren även tillgång till referensgrupper i verksamhetsfrågor och tekniska frågor. Produktägaren deltar även fysiskt tillsammans med områdesproduktägaren, domänexperten och ScrumMaster vid Sprint Review. 2.1.2 Verksamhetsteam Verksamhetsteamet består, som namnet beskriver, av representanter från verksamheten. Varje medlem i teamet kan komma att ha olika roller i olika skeden i projektet. Framförallt är det följande roller som är aktuella: Utredare Assistera Produktägaren vid utredning/detaljering av aktiviteter i Product Backlog. Områdesproduktägare Representera produktägaren i projektteam med ett Scrum-team. Domänexpert Tillsammans med Scrum-teamet analysera och detaljera krav i en domän för en Sprint
Sida 4 av 14 Verksamhetstestare Utföra utforskande tester i ett Scrum-team, som komplement till de automattester utvecklarna kör. 2.1.2.1 Områdesproduktägare Fungerar som huvudproduktägarens förlängda arm i arbetet kring en Sprint. Områdesproduktägaren ska tillsammans med Scrum-teamet vid Sprintplaneringen, plocka ut de aktiviteter från Product Backlog, som ska ingå i Sprinten. Områdesproduktägaren har normalt en djupare kunskap än produktägaren inom det utvecklingsområde i Sprinten hanterar och arbetar tätt ihop med teamet under hela Sprinten. Rollen som områdesproduktägare i en projektteam, behöver inte vara en heltid, utan områdesproduktägaren kan även ha andra roller i andra Sprintar eller utredningar parallellt. Däremot är det nödvändigt att områdesproduktägaren är tillgänglig för konsultation i olika situationer. Områdesproduktägaren och domänexperten arbetar tillsammans och kan agera backup för varandra för att säkerställa tillgänglighet för Scrum-teamet. Områdesproduktägaren deltar även fysiskt tillsammans med produktägaren, domänexperten och ScrumMaster vid Sprint Review. 2.1.2.2 Domänexpert Begreppet domänexpert kommer från användningen av domän-driven utveckling (DDD), som projektet ska använda sig av vid analys och design av Ladok3. Domänexperten motsvaras av användaren i Scrum, d v s den som har detaljerad kunskap om hur systemet ska användas och vilka krav som finns. Domänexperten ansvarar även för att man använder gemensamma begrepp vid beskrivning av domänen. Domänexperten arbetar tillsammans med Scrum-teamet främst i analysfasen kring den domän teamet ska arbeta med. Domänexperten arbetar även fortsättningsvis tätt tillsammans med Scrum-teamet under hela Sprinten för att säkerställa att alla oklarheter och frågor som kan dyka upp under arbetet, kan bli besvarade utan fördröjning. Domänexperten och områdesproduktägaren arbetar tillsammans och kan agera backup för varandra för att säkerställa tillgänglighet för Scrum-teamet. Domänexperten deltar även fysiskt tillsammans med produktägaren, områdesproduktägaren och ScrumMaster vid Sprint Review, för att granska hela resultatet från Sprinten. 2.1.2.3 Verksamhetstestare Verksamhetstestaren är en del av projektteamet och ansvarar för att utföra utforskande tester, d v s ställa sig frågor som vad händer om jag gör så här, både utifrån vad man ska kunna göra och även vad man inte ska kunna göra. Genom att samarbeta med Scrum-teamet får verksamhetstestaren insyn i lösningen och kan ta fram lämpliga utforskande tester under ledning av Senior Testarkitekt. Eftersom verksamhetstestaren och Scrum-teamet troligen inte sitter
Sida 5 av 14 tillsammans måste eventuell dialog och deltagande ske m h a exempelvis Adobe Connect om fysisk närvaro inte är möjlig. 2.1.2.4 Utredare Utredaren är en del av projektteamet och arbetar med olika typer av utredningar för att klargöra oklarheter i Product Backlog på uppdrag av Produktägaren. 2.1.3 Referensgrupper Produktägare har förutom verksamhetsteamet två referensgrupper till sitt förfogande och stöd i olika frågor: Dels finns en referensgrupp som stöd för verksamhetsrelaterade frågor. Denna grupp är utsedd av systemägarna på de olika lärosätena, det vill säga expertgruppen för strategiska frågor. Som stöd för olika tekniska frågor finns även en referensgrupp utsedd av IT-cheferna vid lärosätena. 2.1.4 Lösningsansvarig Ansvar Genomföra arbetet inom lösningsorganisationen med resultat enligt kravoch lösningsbeskrivning samt inom ramarna för projektdirektiv och projektplan Producera, leverera och överlämna rätt resultat Planera, leda, följa upp och styra produktionsarbetet inom lösningsorganisationen Identifiera och införa förbättringar i arbetssättet Säkerställa att överenskomna metoder och verktyg används Rapportera och informera om aktiviteternas status Utveckla, förvalta och hushålla med resurserna Säkerställa att alla resultat har korrekt innehåll och sammansättning samt att de är återskapningsbara Begära beslut från produktägaren i vägval som får stora konsekvenser på verksamheten eller förvaltningen av systemet. Befogenhet Fatta beslut om tekniska lösningar Nyttja och styra av projektledaren tilldelade produktionsresurser Avvisa inberoenden som avviker från överenskommet innehåll och kvalitet Föra in och lämna ut resultat till och från wikin Organisera demonstrationer 2.1.5 Migreringsansvarig Ansvar Genomföra arbetet inom migreringsorganisationen med resultat enligt krav- och lösningsbeskrivning samt inom ramarna för projektdirektiv och projektplan Producera, leverera och överlämna rätt resultat
Sida 6 av 14 Planera, leda, följa upp och styra produktionsarbetet inom migreringsorganisationen Identifiera och införa förbättringar i arbetssättet Säkerställa att överenskomna metoder och verktyg används Rapportera och informera om aktiviteternas status Utveckla, förvalta och hushålla med resurserna Säkerställa att alla resultat har korrekt innehåll och sammansättning samt att de är återskapningsbara Begära beslut från produktägaren i vägval som får stora konsekvenser på verksamheten eller förvaltningen av systemet. Befogenhet Fatta beslut om tekniska lösningar inom migreringen Nyttja och styra av projektledaren tilldelade produktionsresurser Avvisa inberoenden som avviker från överenskommet innehåll och kvalitet 2.1.6 Projektteam Projektteam innefattar de personer som arbetar med en Sprint. Vissa roller arbetar heltid (främst Scrum-teamet), vissa arbetar deltid (områdesproduktägare, domänexpert, Senior Testarkitekt och användbarhetsexpert) och vissa endast vid enstaka tillfällen (CM, DBA, SA, Produktion). Även om vissa roller enbart gör deltidsinsatser, är det viktigt att dessa finns tillgängliga övriga tider för konsultation i olika frågor. Projektteam uppdrag är att säkerställa leveransen från den aktuella Sprinten. Respektive roll beskrivs i följande kapitel. 2.1.7 Utvecklingsstöd 2.1.7.1 Senior IT-arkitekt Förutom att delta i själva utvecklingen (i ett Scrum-team), ansvarar Senior ITarkitekten för lösningens arkitektur på en övergripande nivå. Det innebär att: följa upp och säkerställa att de lösningar som tas fram av respektive team följer de regler och principer, som fastslagits för systemets arkitektur och design följa upp och vid behov komplettera eller anpassa arkitekturen baserat på erfarenheter från utvecklingen Senior IT-arkitekten ska även stötta Lösningsansvarig vid val av 3:e parts/open source komponenter/produkter, så att detta görs med avseende på teknik. 2.1.7.2 Senior Testarkitekt Senior Testarkitekt ska säkerställa att vald metodik för tester efterlevs av projektteamen, samt att den löpande utvärderas och utvecklas under projektets gång. Senior Testarkitekt arbetar därför med projektteamet och ska leda och säkerställa testarbetet i projektet. Senior Testarkitekt ansvarar för att säkerställa att testdata hanteras på ett sätt som tar hänsyn till de juridiska aspekter som gäller för persondata.
Sida 7 av 14 Senior Testarkitekt ansvarar för att olika aspekter av den valda arkitekturen täcks upp i testerna i alla steg från enhetstest, via systemtester till acceptanstester Senior Testarkitekt ska leda och hjälpa verksamhetstestarna med att hantera och dokumentera de utforskande testerna, för att säkerställa beteende och funktion i systemet. Senior Testarkitekt ska även leda och hjälpa utvecklarna att ta fram relevanta automattester med valda verktyg, baserat på de krav som tagits fram. Senior Testarkitekt ska även leda och hjälpa migreringsteamen att ta fram relevanta automattester med valda verktyg, för att säkerställa att informationen förs över korrekt till Ladok3 2.1.7.3 Användbarhet Användbarhetsexperten ansvarar för att projektet arbetar enligt relevanta metoder för användbarhet används enligt ref. [1]. Användbarhetsexperten ansvarar för den grundläggande utformningen av användargränssnittet, samt att användargränssnittet är anpassat för verksamhetens behov, enligt krav och standarder som finns för användargränssnitt. Användbarhetsexperten arbetar tillsammans med produktägare och verksamhetsteamet mot slutanvändare och utvecklare för att säkerställa produktens användarbarhet. Användbarhetsexperten fungerar som en stödperson till alla Scrum-team med ovanstående funktioner. 2.1.7.4 CM Configuration Manager (CM) ansvarar för att man hanterar källkod enhetligt i versionshanteringssystemet, ta fram automatiseringsscript för att bygga, paketera och leverera systemet. CM fungerar som en stödperson till alla Scrum-team med ovanstående funktioner. 2.1.7.5 DBA Database administrator (DBA) ansvarar bland annat för att datalagringen för programvaran fungerar, hanterar behov av indexering och konfigurering, ta fram backuphantering. DBA fungerar som en stödperson till alla Scrum-team med ovanstående funktioner. 2.1.7.6 SA Systemadministratören (SA) ansvarar för att installera, uppgradera, konfigurera och övervaka de utvecklings- och testsystem som används. SA ansvarar även för att säkerställa drift och övervakning av systemet bör även representant från driftsorganisation medverka som stödperson i projektteamet. SA fungerar som en stödperson till alla Scrum-team med ovanstående funktioner.
Sida 8 av 14 2.1.8 ScrumMaster ScrumMasterns huvuduppgift är att säkerställa att Scrum-teamet kan arbeta så effektivt som möjligt. ScrumMastern är inte en del av teamet, men är dess ledare och stöd och ska skydda Teamet från all yttre störning. ScrumMastern är inte heller ansvarig för leveransen av produkten. Då flera team arbetar parallellt måste teamens arbete samordnas, via så kallade Scrum of Scrum möten, för att exempelvis samordna överlappande aktiviteter mellan Scrum-teamen. ScrumMaster deltar i dessa tillsammans med en lämplig teammedlem. ScrumMaster ska även: Säkerställa att de agila idéerna är förstådda och respekterade av alla intressenter. Hjälpa till att förbättra Teamets produktivitet genom att t ex säkerställa att man återkopplar erfarenheter. Arbeta tillsammans med (Områdes)Produktägaren för att maximera resultatet. 2.1.9 Scrum-team Scrum-teamet består av den kompetens som krävs (tvärfunktionellt krav, design, test, etc.) för att utveckla den programvara teamet tagit ansvar för. Teamet ska: Leverera produkten och är ansvarig för dess kvalitet Arbeta tätt ihop med (Områdes)Produktägaren, Domänexperten och Senior Testarkitekt, för att inhämta nödvändig information för analys och kravdetaljering Ta fram design, utveckla, testa och leverera produkten enligt överenskommelse Ansvara för sitt arbete som en del i projektet Samarbeta med (Områdes)Produktägaren för den strategiska inriktningen av produktens utveckling Arbeta med Sprint Backlog och leverera tillbaka eventuella nya behov till Product Backlog Då flera team arbetar parallellt måste teamens arbete samordnas, via så kallade Scrum of Scrum möten, för att exempelvis samordna överlappande aktiviteter mellan Scrum-teamen. Teamet ska för dessa utse en deltagare från teamet, som tillsammans med ScrumMaster deltar i dessa. 2.1.9.1 Arkitekt Varje team ska ha en utvecklare med ansvar för arkitekturen på den/de modul(er) man utvecklar. Denna utvecklare ska fungera som Senior IT-arkitektens förlängda arm i teamet och ska säkerställa att man följer de regler och principer som fastslagits för systemets arkitektur och design. 2.1.9.2 Utvecklare Utvecklarna är en del av Scrum-teamet och är ansvariga för att tillsammans med bland annat (områdes)produktägaren, domänexperten och Senior Testarkitekt analysera, estimera, designa, utveckla och testa den/de funktion(er) de åtagit sig i en Sprint. Utvecklarna ska företrädesvis sitta tillsammans.
Sida 9 av 14 3 Artefakter 3.1 Product Backlog Product Backlog är en samlingsplats för alla krav/önskemål om nya funktioner och förändringar av produkten/systemet. Product Backlog ägs och hanteras av produktägaren. Det finns ingen begränsning på antal önskemål i Product Backlog. I stället används prioritering. Ju högre prioritet, desto bättre specificerat ska ändringsönskemålet vara. Varje krav är grovt tidsuppskattat av projektteamet. 3.2 Sprint Backlog Sprint Backlog är den del av en product backlog som Scrum-teamet åtar sig att implementera under den kommande sprinten, d v s Scrum-teamets arbetslista. Sprint Backlog kan ofta vara endast en vy mot Product Backlog på de delar som ingår i sprinten. 3.3 Dokumentation Förutom Product och Sprint Backlog dokumenteras även resultatet från det arbete som görs kopplat till analys, design, test och användardokumentation som görs i samband med sprintarna. Denna dokumentation hanteras med hjälp av en Wiki (en versionshanterad sökbar webbplats, där sidorna enkelt och snabbt kan redigeras av behöriga besökare via ett webbgränssnitt, jämför t ex Wikipedia). Wiki:n används för att dokumentera de resultat domänmodelleringen ger i form av begrepp i respektive domän, domänmodell, User Stories med regelverk, övriga noteringar, samt användardokumentation för de delar som bearbetas. I slutet av projektet tas en systemdokumentation (Software Architecture Document, SAD), som beskriver det slutgiltiga systemet. 3.4 Teman Teman är en leverans av en sammansättning av flera sammanhörande sprintar relaterat till ett visst funktionellt område. Tanken med teman är att kunna få tillfälle att demonstrera mer omfattande funktionalitet för en större krets intressenter och på så sätt få en bredare förankring av arbetet. Uppdelningen av projektet i olika teman, används även som underlag för en grov övergripande plan för projektet. 4 Produktionsmodell Nedanstående figur visar en övergripande bild av produktionsmodellen för Ladok3 projektet och relaterade delar inom förvaltningen och de lokala lärosätena. Flödet går från övre vänstra hörnet till nedre högra hörnet.
Sida 10 av 14 Lösningsdelen och migreringsdelen i projektet drivs agilt i sprintar. Sprintarna levererar kontinuerligt delresultat av lösning och migrering. Dessa sätts sedan samman till större leveranser, så kallade teman, som används för bredare test, spridning och förankring. Dessa teman kommer även att levereras till Driftestmiljön för att möjliggöra tester för de lokala lärosätena i en produktionslik miljö. Parallellt med detta pågår lärosätenas förberedelser med hantering av datatvätt, verifiering av konvertering, samt anpassning av integrationer. I senare delen av utvecklingsprojektet görs en första delleverans (1) till förvaltningen. Denna delleverans bildar även den första delleveransen till lärosätena för införande i produktion och motsvarar block 1, Underlag redovisning i Backa in preparerad. Utveckling och tester fortsätter i Ladok3- projektet fram till dess slutleverans görs till förvaltningen, varefter lösningsdelen i projektet avslutas. Förvaltningen tar därmed över förvaltningen av lösningen och kommer vid behov korrigera och komplettera lösningen parallellt med införande av övriga delleveranser. På motsvarande sätt fortsätter migreringsdelen därefter med att ge stöd till förvaltning och lärosätena under införande av de efterföljande delleveranserna (resterande block i Backa in preparerad ). 4.1 Utvecklingsprocessen Nedanstående figur beskriver övergripande de olika stegen i utvecklingsprocessen.
Sida 11 av 14 Figur 2 Utvecklingsprocessen för Ladok3 Utvecklingsprocessen utgår från det underlag, som tagits fram dels i verksamhetsdelprojektet (processbeskrivningar, informationsmodell och ickefunktionella krav) och dels i lösningsdelprojektet (lösningsförslag, arkitektur). Utvecklingsprocessen arbetar enligt de principer som beskrivs i Scrum, d v s i små tvärfunktionella team, som arbetar i små etapper (Sprint) med utveckling av en väldefinierad delmängd av systemet. För mer information om detta, se [ref 1]. 4.1.1 Bearbetning av Product Backlog Grunden till Product Backlog är det underlag, som tagits fram i verksamhetsdelprojektet. Dessa beskrivningar bearbetas av produktägaren till en detaljnivå, som sedan kan användas som underlag för Scrum-teamen. Eventuella oklarheter i underlaget i Product Backlog måste utredas och klargöras i god tid före de Sprintar som ska ta hand om utvecklingen. I det arbetet ingår även att prioritera ordningen i Product Backlog, så att de viktigaste delarna utvecklas först. Nya aktiviteter / User Stories kan även tillkomma, som resultat från det arbete som utförs i Sprintarna. 4.1.2 Sprintplanering Sprintplaneringen görs i samarbete mellan produktägaren och projektteamet (områdesproduktägaren, domänexperten, testare, ScrumMaster och Scrumteamet). Vid sprintplaneringen går man igenom de högst prioriterade delarna en och en och skapar/kompletterar/uppdaterar motsvarande domänmodell, samt diskuterar igenom vilka krav som gäller, vilka tester som bör utföras, samt vilka acceptanskriterier som gäller. För varje del i Product Backlog ska Scrum-teamet själv även försöka bedöma om man hinner med det i Sprinten. Mellan varje del bör man även ta en paus. I slutet ska Scrum-teamet själv göra en slutlig bedömning om det är realistiskt att man hinner med del genomgångna delarna. Om detta inte är fallet återlämnas den/de sista del(arna). Kvarvarande delar bildar Sprint Backlog.
Sida 12 av 14 Produktägaren, områdesproduktägaren, domänexperten och testare informeras om resultatet. 4.1.3 Design Nästa steg i arbetet är att Scrum-teamet, baserat på det underlag man arbetat fram (begrepp, domänmodell, regler och övriga krav), ska ta fram en lämplig design för innehållet i Sprint Backlog och dela upp det i motsvarande olika aktiviteter. Därefter tar varje teammedlem varsin aktivitet och börjar utvecklingsarbetet. Då oklarheter och frågor uppkommer kring krav kontaktar teamet i först hand motsvarande domänexpert för konsultation. 4.1.4 Daglig Scrum Varje morgon har Scrum-teamet en s k Daily Scrum, där man kort går igenom gårdagens arbete (vad man gjort, eventuella problem), samt vad man ska göra innevarande dag. Då oklarheter och frågor uppkommer kring krav, kontaktar teamet i först hand motsvarande domänexpert för konsultation och i andra hand produktägaren. Eventuella övriga problem och frågeställningar tar ScrumMaster hand om och ser till att de blir lösta. 4.1.5 Sprint Review I slutet av varje Sprint ska det färdiga resultatet demonstreras främst för produktägare och domänexpert. Sprint reviewen börjar med att produktägaren sammanfattar innehållet i och målet med Sprinten. Utvecklingsteamet går igenom och demonstrerar den nya funktionaliteten. Produktägaren och domänexperten får även själva möjlighet att prova den nya funktionaliteten, samt även granska den framtagna dokumentationen. Kommentarer och förslag dokumenteras av produktägaren och/eller ScrumMaster, samt återförs till Product Backlog för senare åtärder. 4.1.6 Sprint Återblick Innan Scrum-teamet går vidare ska det slutligen göra en återblick och gå igenom vad som fungerat bra och vilka eventuella problem man haft, samt hur man kan åtgärda dessa till nästa Sprint. Problemen kategoriseras på vad man kan själva åtgärda och vad man själv inte kan hantera. Problem man inte själv kan hantera läggs till problemlogg för åtgärd av ScrumMaster. 4.2 Leveranser och miljöer Ladok3-projektet kommer att ha flera olika typer av leveranser enligt nedanstående figur. Figuren beskriver översiktligt de miljöer, som projektet kommer att använda och vilka leveranser som sker mellan miljöerna. Bygg/test hanterar automatisk byggning av systemet, samt automattester [utveckling]
Sida 13 av 14 SprintTest används för olika typer tester t ex utforskande tester [utveckling] MigrTest används för test av migreringslösningarna [migrering] LevTest används för systemtester, samt demonstration av Teman [utveckling/migrering] DriftTest används för integrationstester, kontinuerlig test/utvärdering av de lokala lärosätena [förvaltning] AcceptansTest används för acceptanstest av de delleveranser som ska ske till produktionsmiljön [förvaltning] Drift [förvaltning] De flesta eller alla utvecklare kommer att ha sin egen utvecklings och testmiljö för de delar man arbetar med. Den utvecklade och enhetstestade koden checkas in i versionshanteringssystemet. Med jämna mellanrum körs en byggning och motsvarande test av systemet i Bygg/test (gemensamt utveckling och migrering). Sprintarnas levereras därefter till SprintTest -systemet i figuren, där körs ytterligare tester av testare, exempelvis utforskande tester. I MigrTest testas migreringsdelarna separat för att säkerställa hanteringen av informationsöverföring, konvertering och lagring. Då alla tester och godkänts i SprintTest respektive MigrTest, görs leverans till Lev.test. Efter överenskommen utprovningstid och godkännande i Lev.test -systemet, levereras temat till förvaltningen för införande i Drifttest för fortsatta tester och demonstrationer.
Sida 14 av 14 5 Referenser 1. PM utvecklingsmetodik i Ladok3, v1.0. 2. Agile Software Requirements, Lean Requirements Practices for Teams, Programs, and the Enterprise; Dean Leffingwell. ISBN-13:978-0321-63584-6 3. Agile Testing, A practical Guide For Testers an Agile Teams; Lisa Crispin, Janet Gregory. ISBN-13: 978-0-321-53446-0. 4. Practices for Scaling Lean & Agile Development, Large, Multisite, and Offshore Product Development with Large-Scale Scrum; Craig Larman, Bas Vodde. ISBN-13 978-321-63640-9