Protokoll fört vid möte med förvaltningsgruppen för KursInfo

Transkript

1 Dokumentttyp Datum Utgåva Sida PROTOKOLL (4) Utfärdat av Pr_forv_ _2.doc Protokoll fört vid möte med förvaltningsgruppen för KursInfo Datum & Tid: kl kl Plats: Quality Hotel Växjö Syfte: Möte med förvaltningsgruppen för KursInfo Närvarande ledamöter Förvaltningsgruppen Magnus Blom Högskolan i Jönköping Emma Norrbin Malmö högskola Karin Eldholm Högskolan i Skövde Jenny Welander Blekinge tekniska högskola Jenny Anderbjörk Högskolan i Borås Ordförande Cecilia Barne Linnéuniversitetet Stefan Hallstedt Högskolan i Halmstad Övriga närvarande Högskolan i Skövde Sekreterare Mikael Åhgren Högskolan i Skövde Utvecklingsteamet Kjell Sjökvist Högskolan i Skövde Utvecklingsteamet Madeleine Andren Linneuniversitetet Ej närvarande 1 Mötet öppnas Ordföranden hälsade alla välkomna och förklarade mötet öppnat. 2 Fastställande av dagordning Dagordningen godkänndes utan tillägg. 3 Föregående mötes protokoll Protokollet från föregående möte gicks igenom. 5: Någon Beta 2 har inte levererats utan en version 1.0 RC1 har levererats istället. 6: Pilotprojektet för införande i Skövde har inte blivit i den omfattning som var planerat p.g.a. personal- och tidsbrist. 7: Förvaltningsgruppsmötet ska vara i Växjö istället för Jönköping. Protokollet lades till handlingarna. 4 Arbetssätt i förvaltningen av nya KursInfo Förslaget till arbetssätt i förvaltningen av nya KursInfo (bilaga 1) gicks igenom och arbete med att justera detta påbörjades. Några ytterligare tillägg behöver göras och Håkan fick i uppdrag att göra förslag till dessa. Dokumentet tas upp för beslut vid nästa förvaltningsgruppsmöte. 5 Frekvens för nya planerade versioner Enligt tidsplan kommer LNU, som första lärosäte, att genomföra införande av nya KursInfo vecka 21. Därefter kommer Mah vecka 23, BTH vecka 25, HS vecka 34 och HJ vecka 37. Någon tidpunkt för införande vid HH och HB är ännu inte fastställt. Med utgångspunkt från att det kommer att genomföras ett testprojekt under april maj och att förberedelserna inför införandena på lärosätena troligen kommer att generera en del arbete bl.a. med att rätta buggar behöver utvecklingsteamet finnas tillgängligt för att ta hand

2 Dokumentttyp Datum Utgåva Sida PROTOKOLL (4) Utfärdat av Pr_forv_ _2.doc om detta under våren och sommaren. Utvecklingsteamet behöver också vara tillgängliga för tekniskt stöd i samband med de lokala införandena, vilket innebär att det inte är lämpligt att planera in någon nyutveckling före semesterperioden. Förvaltningsgruppen beslutade att utvecklingsteamet får förfoga över utvecklingstiden under perioden vecka och under denna period bedömer vad som behöver göras och levererar buggrättningar när det är lämpligt. Utvecklingsteamet föreslog en frekvens för leverans av nya versioner till en gång per kvartal och en modell med sprintar som går över tre veckor per sprint. Varje leveransperiod blir då 13 veckor med fyra treveckors-sprintar och en vecka för paketering och leverans på slutet (bilaga 2). Sprintarna benämns med år och löpnummer, 2014:1 2014:6 under 2014 och därefter 2015:1 o.s.v. Förvaltningsgruppen beslutade enligt förslaget. Vad är en bugg? Buggar kan vara av både allvarlig art, s.k. showstoppers som stoppar systemet för att fungera eller leverera det som systemet ska eller mindre allvarlig art som inte påverkar systemets funktioner i större utsträckning eller att det finns sätt att komma runt problemet tills vidare. Samtliga hittade buggar rapporteras till adressen bugg@kursinfo.nu. Inrapporterade buggar verifieras av samarbetets testfunktion och utvecklingsteam för att avgöra om det är en bugg samt av vilken art den är. Buggar av mindre allvarlig karaktär läggs i en bugglista som prioriteras in i backloggen tillsammans med övriga önskemål och planeras in i kommande sprintar för ordinarie leverans. Förvaltningsgruppen avgör om en bugg är en showstopper som kräver en extra leverans med buggfix för detta. Vid oenighet ska majoritetsbeslut gälla och vid lika röstetal har förvaltningsgruppens ordförande utslagsröst. 6 Tidplan för kvartal samt 2015 Förvaltningsgruppen beslöt att de första fyra sprintarna med leverans av ny funktionalitet ska påbörjas vecka 35 med leverans i vecka 47. Planering för kvartal beslutades enligt bilaga 3. Planerade releasedatum för 2015 beslutades till fredagarna i vecka 8, 21, 34 och 47 med planering enligt bilaga 4. Samma leveransdagar ska sedan gälla löpande kommande år. 7 Prioriteringsmatris för kommande arbete Förvaltningsgruppen beslutade att alla önskemål i KursInfo ska kategoriseras enligt: Systemdel Kursinfo Generellt GEN Editor Generellt EDI Editor Kurs EKU Editor Program EPR Editor Kt EKT Editor Pt EPT Editor Kurspaket EKP Editor Publikation - EPU Sök Generellt SOK Sök Kurs SKU Sök Program SPR Sök Kt - SKT Sök Pt SPT Sök Kurspaket SKP Admin ADM Databas DBS XML Leverans XML Rapporter Generellt RAP

3 Dokumentttyp Datum Utgåva Sida PROTOKOLL (4) Utfärdat av Pr_forv_ _2.doc Kat A B C Beskrivning Fel som stoppar systemet generellt (Show-stopper) Vidareutveckling B.1 Nyttjas av alla B.2 Nyttjas av en eller några Fel som är av mindre allvarlig art och inte är akuta att åtgärda C.1 Nyttjas av alla C.2 Nyttjas av en eller några Utvecklingsteamet går igenom och gör en grov tidsuppskattning för inkomna önskemål, t.ex. i omfattning av dagar, veckor eller månader så att förvaltningsgruppen får en uppfattning om hur stora önskemålen är. Förvaltningsgruppen beslutade att prova en modell där varje lärosäte väljer ut fem önskemål ur önskemålslistan och prioriterar dessa inbördes. Vid förvaltningsgruppsmöte görs sedan en prioritering av samtliga prioriterade önskemål där varje förvaltningsgruppsmedlem får 15 poäng att fördela på dessa. Därefter görs en prioriteringslista av önskemålen som ligger till grund för backloggen. 8 Systemförvaltningsplan 2014 Förslaget till systemförvaltningsplan gicks igenom och justerades (bilaga 5). Några ändringar kvarstår som Håkan genomför innan systemförvaltningsplanen lämnas till styrgruppen. 9 Förändringar i NyA som påverkar XML UHR har genomfört förändringar i Nya och antagning.se som påverkar vår gemensamma XML. I flera fall har ändringar gjorts utan att detta har meddelats och i vissa fall har detta meddelats med mycket kort framförhållning. Förvaltningsgruppen beslutade att skicka denna fråga till styrgruppen för att ta upp detta med UHR så att vi får tidig och tydlig information kring kommande förändringar så att vi kan planera in detta i vårt arbete. Jenny Anderbjörk har fått en lista från UHR med genomförda förändringar som vi inte fått meddelande om. Denna fråga fick bordläggas till senare möte där förvaltningsgruppen får besluta kring hur detta ska hanteras. 10 Övriga frågor Mall för kravspecifikationer lämnade ut ett förslag till mall för kravspecifikationer i förvaltning av KursInfo (bilaga 6). Mallen är relativt omfattande, men punkterna ska ses som en checklista över frågor och uppgifter som kan behövas för utveckling av funktionen. Ju fler frågor och oklarheter man kan lösa i samband med kravställandet desto mindre frågor behöver redas ut när funktionen ska utvecklas. 11 Nästa möte Kommande fysiska möten med förvaltningsgruppen beslutades till: i Borås (10.00 dag dag 2) i Karlskrona i Halmstad Förvaltningsgruppen beslutade även att ha korta avstämningsmöten via Adobe Connect varje vecka på torsdagar mellan kl Undantag från dessa dagar är: vecka 16: , kl vecka 18: , kl

4 Dokumentttyp Datum Utgåva Sida PROTOKOLL (4) Utfärdat av Pr_forv_ _2.doc vecka 22: , kl Inget möte i vecka 24, 34 och 47. Inför avstämningsmötet den gäller följande tidsplan: Förvaltningsgruppens medlemmar tar fram fem önskemål ur önskemålslistan och prioriterar dessa (1-5). Den prioriterade listan skickas till Jenny Anderbjörk senast Jenny skickar sedan ut en sammanställd lista med allas prioriterade önskemål inför avstämningsmötet , där en gemensam prioritering görs. 12 Mötet avslutas Ordförande tackade för dagens möte och förklarade mötet avslutat. Vid protokollet: Justeras:, sekreterare Jenny Anderbjörk, ordförande

5 Dokumenttyp Datum Utgåva Sida ARBETSMODELL P1.0 1 (4) Dokumentansvarig Bilaga 1 Arbetssätt vid förvaltning av KursInfo SCRUM ála KursInfo Roller och grupper KursInfo styrgrupp Styrgruppen är produktägare och fattar övergripande beslut kring produkten och dess förvaltning. KursInfo förvaltningsgrupp Förvaltningsgruppen är produktförvaltare som ser till att utvecklingsteamet arbetar med rätt saker ur ett verksamhetsperspektiv. Förvaltningsgruppen administrerar en produktbacklog en förändringsbar att-göra-lista där alla krav och önskemål för produkten listas efter verksamhetsnytta. Backloggen är synlig för styrgrupp, förvaltningsgrupp, utvecklingsteam och uppdragsledaren så att alla är medvetna om vilka förändringar som kan förväntas i kommande releaser av produkten. Ytterst ansvarig för produktbacklogen är förvaltningsgruppens ordförande. Förvaltningsgruppen ansvarar för att skriva kravspecifikationer utifrån beslutade önskemål från backloggen. Kravansvarig Kravansvarig är en medlem i förvaltningsgruppen eller annan person som får uppdraget att representera produktförvaltarens krav i en specifik sprint. Utvecklingsteam Utför arbete som problemlösare, konstruktörer och testare. Hur arbetet läggs upp och hur uppgifterna fördelas bestäms av teamets medlemmar. Teamet saknar fasta roller. Detta hindrar naturligtvis inte att enstaka medlemmar är specialister på ett område. Sprintledare Sprintledaren är en kombination av coach, fixare och dörrvakt. Huvudsakligen arbetsleder och stödjer sprintledaren sprintteamet för att säkerställa att de har de allra bästa förutsättningarna för att lyckas. I de fall någon utanför sprintteamet har något ärende att ta upp med teamet angående sprinten, tas detta upp med sprintledaren i syfte att teamet ska störas så lite som möjligt i sitt arbete. Sprintteam Utvecklingsteamet, kravansvarig och sprintledaren utgör det som kallas för sprintteam och ansvarar tillsammans för att produkten levereras i tid, med rätt innehåll och med rätt kvalitet.

6 Dokumenttyp Datum Utgåva Sida ARBETSMODELL P1.0 2 (4) Dokumentansvarig Tillvägagångssättet Önskemålshantering Nya önskemål skickas löpande till uppdragsledaren som sammanställer dessa på en önskelista som är synlig för förvaltningsgruppen. Att skapa en backlogg Förvaltningsgruppen beslutar kring varje önskemål om detta ska läggas till i backloggen, utser vem som ska skriva kravspecifikationerna och utser kravansvarig. När kraven har skrivits, styckas helheten i delar. Varje sådan del ska skapa systemnytta/verksamhetsnytta samt gå att färdigställa. Förvaltningsgruppen gör en prioritering - I vilken ordning ska förändringarna genomföras och levereras? Resultatet blir en backlogg som sorteras om efter hur verksamhetens och externa krav förändras över tiden. Här prioriteras även inkomna buggar som är verifierade av utvecklingsteamet. När det är dags att sätta igång en ny sprint fryser förvaltningsgruppens ordförande backloggen och kallar sprintteamet till möte. Kravspecifikation För varje önskemål/funktion som ska utvecklas ska det finnas en detaljerad och godkänd kravspecifikation. Det finns flera syften med att ta fram en kravspecifikation och dessa är i huvudsak: förstå uppgiften reflektera över konsekvenser och risker bli överens vara grund för tidsuppskattning vara underlag för systemtest För kravspecifikationer finns en särskild framtagen mall som ska användas. Underhåll av backlogg För att sprintplaneringen ska gå smidigt behöver backloggen underhållas och det görs av hela förvaltningsgruppen i samråd med utvecklingsteamet. Underhållet består till exempel av estimering och nerbrytning av krav i Work Items så att de ryms inom en sprint. Det kan vara bra att avsätta en viss tid varje vecka till underhåll av backlogg, gärna vid samma tidpunkt och på samma plats för att underlätta planeringen av mötet. Sprinten Av sprintens arbetsdagar avsätts den första till att skapa en sprintbacklog. När man är överens om uppgifter och tidsåtgång släpper förvaltningsgruppens ordförande taget och sprintteamet arbetar på egen hand. Sprintteamet avgör hur mycket arbete som ryms inom sprinten. Sprintmöten Sprintteamet håller korta regelbundna möten. Syftet är att synkronisera utvecklingen samt att identifiera och lösa eventuella problem som hindrar teamet att göra sitt jobb. Under mötet svarar deltagarna på tre frågor: Vad har du gjort sedan förra mötet? Vad tänker du göra inför nästa möte?

7 Dokumenttyp Datum Utgåva Sida ARBETSMODELL P1.0 3 (4) Dokumentansvarig Är det något som hindrar dig från att uträtta ditt planerade arbete? De två första frågorna ger mötesdeltagarna full insyn i hur projektet fortskrider. Den tredje frågan ger underlag för problemlösning det kan vara allt från tekniska problem till störmoment utifrån. Sprintutvärderingsmöte Förvaltningsgruppen och sprintteamet har ett sprintutvärderingsmöte efter varje sprint. Mötet består av två delar demo, där leveransen demonstreras av kravansvarig, och sprintåterblick, där sprintteamet reflekterar och drar lärdom av de erfarenheter som har gjorts i sprinten. Syftet är att se till så att alla är medvetna om vad som har hänt i sprinten och öka motivationen inför nästa sprint. Bugghantering Samarbetets testfunktion tar hand om och verifierar alla inkomna buggar inom samarbetet. Buggarna kategoriseras i kategori 0 (showstoppers och 1 (mindre allvarliga buggar). Förvaltningsgruppen gör en bedömning om en bugg ska kategoriseras som kategori 0, vilken då ska åtgärdas och skickas ut som en extra leverans. Buggar med kategori 1 lägga in i backloggen för prioritering och hantering i ordinarie sprintar och levereras med ordinarie leveranser.

8 Dokumenttyp Datum Utgåva Sida ARBETSMODELL P1.0 4 (4) Dokumentansvarig Tillgängliga resurser för arbetet Ordförande i förvaltningsgruppen 1 st 15% av heltid = 25 tim/månad Förvaltningsgruppens medlemmar 7 st 15% av heltid = 174 tim/månad (25 tim/pers) Uppdragsledare 1 st 50% av heltid = 83 tim/månad Utvecklare 3 st 100% av heltid = 495 tim/månad (165 tim/pers) Testare 1,5 st 100% av heltid = 247 tim/månad (165 tim/pers) Summa = 1024 tim/månad

9 Bilaga 2 Tidplan för sprintar och leveranser av uppdateringar veckor / 1 kvartal Sprint 1 Sprint 2 Sprint 3 Sprint 4 V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 Planering /Work Items/Demo/Återblick Planering /Work Items/Demo/Återblick Planering /Work Items/Demo/Återblick Planering /Work Items/Demo/Återblick Paketering Leverans Alternativt läge Sprint 1 Sprint 2 Sprint 3 V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 Återblick/Planering/ buggfixar Planering /Work Items/Demo/Återblick Planering /Work Items/Demo/Återblick Planering /Work Items/Demo/Återblick Buggfixar/Paketering Leverans

10 Bilaga 3 Planering kvartal 2-4, 2014 April 2014 Maj 2014 Juni 2014 Juli 2014 Augusti 2015 September 2015 Oktober 2015 November 2015 December 2015 V14 V15 V16 V17 V18 V19 V20 V21 V22 V23 V24 V25 V26 V27 V28 V29 V30 V31 V32 V33 V34 V35 V36 V37 V38 V39 V40 V41 V42 V43 V44 V45 V46 V47 V48 V49 V50 V51 V52 PREL. SEMESTER Sprint 1 Sprint 2 Sprint 3 Sprint 4 P/L Sprint 5 Sprint 6 V14-34 Utvecklingsteamet förfogar över all utvecklingstid för buggrättningar, bugguppdateringar samt stöttar tekniskt vid införanden. Testprojektet levererar sitt resultat och buggar rättas så att vi får en skarp V1.0. Förvaltningsgruppen påbörjar sitt arbete med prioriteringar, bygga backlogg samt skriva krav för sprint 1 och 2. Utser kravansvarig till första sprintarna. V35-47 Första paket med 4 sprintar utvecklas och levereras i vecka 47 Förvaltningsruppen fortsätter med uppdatering av backlogg samt kravspecar för de högst prioriterade kraven i backloggen Utser kravansvarig till nästkommande sprintar. V48-52 Andra paket med sprint 5 samt delar av sprint 6 börjar utvecklas. Förvaltningsruppen fortsätter med uppdatering av backlogg samt kravspecar för de högst prioriterade kraven i backloggen Mötestillfällen Förvaltningsgruppen 31/3-1/4 Förvaltningsgruppsmöte (fysiskt), arbetsmodell, tidplan, mm Vecka 24 Förvaltningsgruppsmöte (fysiskt), prioritering av backlog mm Vecka 34 Förvaltningsgruppsmöte (fysiskt), sprintplanering Vecka 47 Förvaltningsgruppsmöte (fysiskt), sprintåterblick och sprintplanering Veckovis Avstämningsmöte & underhåll av backlog (Adobe Connect), 30 min Sprintteam Regelbundna sprintmöten fr.o.m. vecka 35

11 Sprint och release-planering Bilaga Juli 2014 Augusti 2014 September 2014 V27 V28 V29 V30 V31 V32 V33 V34 V35 V36 V37 V38 V39 PREL. SEMESTER Sprint 1 Sprint 2 Oktober 2014 November 2014 December 2014 V40 V41 V42 V43 V44 V45 V46 V47 V48 V49 V50 V51 V52 Sprint 3 Sprint 4 Pack & lev. Sprint 1 Sprint Januari 2015 Februari 2015 mars 2015 V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V3 Sprint 3 Sprint 4 Pack & lev. Sprint 1 Sprint 2 April 2015 Maj 2015 Juni 2015 V14 V15 V16 V17 V18 V19 V20 V21 V22 V23 V24 V25 V26 Sprint 3 Sprint 4 Pack & lev. Sprint 1 Sprint 2 Juli 2015 Augusti 2015 September 2015 V27 V28 V29 V30 V31 V32 V33 V34 V35 V36 V37 V38 V39 PREL. SEMESTER Pack & lev. Sprint 1 Sprint 2 Oktober 2015 November 2015 December 2015 V40 V41 V42 V43 V44 V45 V46 V47 V48 V49 V50 V51 V52 Sprint 3 Sprint 4 Pack & lev. Sprint 1 Sprint 2 Leverans av ny version sker fredagar i vecka 8, 21, 34 & 47.

12 Systemförvaltningsplan 2014 KursInfo Samarbetet kring KursInfo

13 Dokumentttyp Datum Utgåva Sida SYSTEMFÖRVALTNINGSPLAN P (14) Utfärdat av Beslut och ikraftträdande Härmed fastställs systemförvaltningsplan för KursInfos gemensamma förvaltning inom KursInfosamarbetet Planen gäller från 2014-xx-xx. Borås den Skövde den Ulrika Bernlo Ordförande, styrgruppen Uppdragsledare Borås den Jenny Anderbjörk Ordförande, förvaltningsgruppen Utgåvehistorik Utgåva Datum Kommentar P xx-xx Förvaltningsplanen upprättas

14 Dokumentttyp Datum Utgåva Sida SYSTEMFÖRVALTNINGSPLAN P (14) Utfärdat av Innehåll Beslut och ikraftträdande... 2 Utgåvehistorik... 2 Innehåll Systembeskrivning Syfte Mål och effekter Samverkan med andra system och processer Roller i förvaltningen av KursInfo Systemägare Systemförvaltare Systemutvecklare Testare Styrning och ledning Styrgrupp Förvaltningsgrupp Organisationsschema Aktivitetsplan Leveransplan Aktiviteter Delaktivitet Delaktivitet Delaktivitet Delaktivitet Möten och uppföljning Förslag på fortsatt utveckling Arbetsmodell... 9

15 Dokumentttyp Datum Utgåva Sida SYSTEMFÖRVALTNINGSPLAN P (14) Utfärdat av SYSTEMFÖRVALTNINGSPLAN Systembeskrivning KursInfo är ett system för att hantera utbildningsrelaterad information. KursInfo används idag av sju lärosäten som också samarbetar kring vidareutveckling av systemet. Den huvudsakliga utvecklingen görs vid Högskolan i Skövde. I KursInfo hanteras all administration av kurser, kurstillfällen, program, programtillfällen samt kurspaket med tillhörande kursplaner, utbildningsplaner och litteraturlistor. Kurser som erbjuds, kommer att erbjudas, eller har erbjudits vid lärosätet finns i systemet. Ett kurs- och programtillfälle avser ett visst antagnings- och/eller registreringstillfälle för en tidsangiven period för en kurs. 2. Syfte Systemets syfte är att förse samarbetets lärosäten med administrativs stöd för att hantera utbildningsrelaterad information före, under och efter att utbildningstillfället sker/har skett. Systemet ska utvecklas så att de lärosäten som är medlemmar i samarbetet får så stor nytta som möjligt av systemet med beaktande av tillgängliga resurser och de direktiv som styrgruppen ger. 3. Mål KursInfo-samarbetet har som mål 2014 att Lyfta produkten från Release Candidate till en skarp version Alla lärosäten ska ha implementerat nya KursInfo Börja arbeta med förvaltning enligt överenskommen arbetsmodell 4. Samverkan med andra system och processer KursInfo samverkar med andra system både på ett lokalt och nationellt plan. På varje lärosäte förser KursInfo andra kringsystem med information. Exempel på detta är t.ex. utbildningssidor och generering av kurs- och utbildningsplaner. Dessa kringsystem ingår dock inte i samarbetet kring KursInfo. På det nationella planet förser KursInfo UHR och andra intressenter (SUSA-navet) med utbildningsinformation via en XML-generering enligt EMIL-standarden. Dessa uppgifter hämtas sedan till NyA, Antagning.se, m.fl. 5. Roller i förvaltningen av KursInfo 5.1 Systemägare Varje lärosäte har en systemägaren för sin lokala installation av KursInfo. Systemägarens ansvar regleras av lokala beslut kring systemförvaltning av KursInfo på det egna lärosätet. Systemägaren eller den denne utser ingår i samarbetets styrgrupp.

16 Dokumentttyp Datum Utgåva Sida SYSTEMFÖRVALTNINGSPLAN P (14) Utfärdat av 5.2 Systemförvaltare Varje lärosäte har en systemförvaltare för sin lokala installation av KursInfo. Systemförvaltarens ansvar regleras av lokala beslut kring systemförvaltningen av KursInfo på det egna lärosätet. Systemförvaltarens ansvar gentemot samarbetet är: att ingå i samarbetets förvaltningsgrupp, att rapportera fel i det gemensamma systemet till samarbetets support-funktion, att ge support till användarna inom det egna lärosätet, att ta emot lokala förbättringsförslag och önskemål gällande KursInfo, att bevaka interna och externa tekniska förändringar som påverkar KursInfo, dess tjänster och verksamhetsprocesser och informera förvaltningsgruppen så att utvecklingsprojekt kan initieras, att delta i arbetet med att skriva krav för och prioritera nya funktioner samt medverka i arbetet med att realisera dessa att testa och godkänna leveranser av nya funktioner och versioner, att inrätta och ansvara för en referensgrupp av användare på det egna lärosätet, att utbilda användare vid det egna lärosätet. Resursbehov i samarbetet 2014: se förvaltningsgrupp nedan. 5.3 Systemutvecklare Utvecklar systemet utifrån styrgruppens direktiv och förvaltningsgruppens beställningar. Resursbehov 2014: 300 % 5.4 Testare Inom samarbetet ska det finnas en testorganisation enligt beslutad teststrategi för testarbete. Testarnas uppgift är att utföra test på nyutveckling och revidering i systemet. Resursbehov 2014: 150 % 6. Styrning och ledning 6.1 Styrgrupp Styrgruppen består av lärosätenas systemägare eller den denne utser att företräda lärosätet. Styrgruppens uppgift är att ta övergripande beslut i ekonomiska frågor, förvaltning samt större justeringar eller utvecklingsprojekt i KursInfo. Styrgruppen leds av en ordförande som utses inom gruppen för ett år åt gången och ska skifta mellan lärosätena. Styrgruppen beslutar om den årliga systemförvaltningsplanen och fördelning av kostnader mellan lärosätena. Förvaltningsgruppen rapporterar till styrgruppen om status på beslutade justeringar och utvecklingsåtgärder. Förvaltningsgruppens ordförande samt uppdragsledaren är föredragande i styrgruppen. Gruppen sammanträder normalt 2 gånger per termin (oftare vid behov). Beräknad tidsåtgång 2014: ca 72 timmar

17 Dokumentttyp Datum Utgåva Sida SYSTEMFÖRVALTNINGSPLAN P (14) Utfärdat av 6.2 Förvaltningsgrupp Förvaltningsgruppen arbetar operativt med att utveckla KursInfo i enlighet med syfte och mål för KursInfo samt enligt de direktiv som styrgruppen ger. Förvaltningsgruppen består av en systemförvaltare från varje lärosäte samt uppdragsledaren och ledas av en ordförande som utses av styrgruppen för ett år åt gången. Ordförandeskapet ska följa samma lärosäte som ordförandeskapet i styrgruppen. Till gruppen kan efter behov utvecklings- och/eller testkompetenser adjungeras in att delta i gruppens arbete. Gruppen arbetar med att: identifiera, sammanställa och prioritera ändringar och utvecklingsbehov för styrgruppen verkställa de beslutade aktiviteterna i systemförvaltningsplanen tillsammans med berörda användare ta fram detaljerade kravspecifikationer till systemutvecklarna för ändringar i funktioner och utveckling av nya funktioner utifrån beslutad systemförvaltningsplan Gruppen träffas normalt en halv timma varje vecka samt ca 8 timmar en gång var annan månad. Därutöver arbetar förvaltningsgruppens medlemmar med förvaltningsuppgifter. Beräknad tidsåtgång 2014: 15 % av heltid per lärosäte (exkl. det lokala arbetet på lärosätet) 6.3 Organisationsschema Styrgrupp Uppdragsledare/ samordnare Förvaltningsgrupp Lokala referensgrupper Utvecklingsteam inkl. testare 7. Aktivitetsplan 2014 Fram till ska utveckling och leverans av det nya gränssnittet ske. Efter leveransen av version 1.0 RC1 kommer införande och förvaltning av systemet enligt inkomna önskemål att ta vid. Dock kommer ingen nyutveckling av funktionalitet att ske före vecka 35 för att ge utvecklingsteamet utrymme till att ta hand om buggar från testprojektet och ev. problem som uppstår i samband med införande av systemet vid lärosätena samt vara behjälpliga i denna process.

18 Dokumentttyp Datum Utgåva Sida SYSTEMFÖRVALTNINGSPLAN P (14) Utfärdat av Utvecklingsteamet behöver även viss tid för att genomföra refaktorisering 1 av utvecklad kod samt tid att införa nytt utvecklingsstöd (Team Foundation Server 2013) med tillhörande processtöd. Förvaltningsgruppen kommer att påbörja arbetet med att besluta kring arbetsmodell och prioritering av inkomna önskemål för kommande versioner. 7.1 Leveransplan Under kvartal 1-3 släpps inga nya versioner av KursInfo utan endast uppdateringar med buggfixar. I vecka 35 påbörjas arbetet med det första sprintpaketet om fyra sprintar. Första versionsuppdatering av KursInfo planeras att komma i vecka 47 och därefter kommer versionssläpp att ske kvartalsvis fredag vecka 8, 21, 34 samt 47 årligen. 7.2 Aktiviteter Delaktivitet 1 Aktivitet: Testprojekt för test av KursInfo 1.0 RC1 Effektmål: Lokalisera och åtgärda huvuddelen av kvarvarande buggar i version 1.0 RC1 Tidsåtgång: 2 månader Mål: Klart Delaktivitet 2 Aktivitet: Ta fram och besluta om en ny arbetsmodell för förvaltning av KursInfo. Effektmål: Få en effektiv och fungerande förvaltning 2 av KursInfo med fokus på verksamhetsnytta med en lika och rimlig arbetsinsats från alla medlemmar i samarbetet. Tidsåtgång: 10 veckor Mål: Beslut taget senast vecka Delaktivitet 3 Aktivitet: Införa nya KursInfo på samtliga lärosäten inom samarbetet. Effektmål: Fasa ut det gamla KursInfo och endast ha en version av systemet att förvalta. Tidsåtgång: 9 månader Mål: Infört på alla lärosäten senast Refaktorisering eller omstrukturering av kod (engelska: refactoring) är en teknik för att stegvis förbättra kvaliteten på programkod. Syftet är att möblera om koden för att få den enklare och därmed mer lättläst, lättare att underhålla och lättare att vidareutveckla. En viktig detalj med omstruktureringen är att funktionaliteten utåt sett ska vara identisk efteråt, det vill säga beteendet på koden ska inte ha ändrats. (Källa: Wikipedia) 2 Förvaltning är fasen där systemet är i drift och där pågående småjusteringar och småförbättringar genomförs med hjälp av återkoppling från verksamheten eller ändrade förutsättningar i de processer som systemet stödjer. Förändringar i systemet resulterar i systemuppdateringar. Här kan även beslut om avveckling av systemet tas.

19 Dokumentttyp Datum Utgåva Sida SYSTEMFÖRVALTNINGSPLAN P (14) Utfärdat av Delaktivitet 4 Aktivitet Sprint 2014:1-4 Effektmål: Utveckla funktionalitet i produkten för att bättre stödja medlemmarnas behov. Tidsåtgång: 13 veckor Mål: Vecka Delaktivitet 5 Aktivitet: Sprint 2014:5-6. Effektmål: Utveckla funktionalitet i produkten för att bättre stödja medlemmarnas behov. Tidsåtgång: 6 veckor Mål: Sprint 2014:6 klar vecka 1, Möten och uppföljning Rapporteringsform Frekvens Sammankallande Deltagare Kommentarer Styrgruppsmöten 4 ggr/år Styrgruppens ordförande Styrgrupp, förvaltningsgruppens ordförande samt uppdragsledare Årlig revidering av systemförvaltningsplanen, årskostnader samt revidering av aktiviteter och beslut om nya aktiviteter. Förvaltningsgruppsmöten 1 gång/vecka (30 min) samt 1 gång per kvartal Förvaltningsgruppens ordförande Förvaltningsgrupp och uppdragsledare. Övriga kan adjungeras vid behov. Följa upp sprintarbetet. Behandla inkomna önskemål om förändringar, prioriteringar, besluta kring kravspecifikationer, etc. Sprint-möte Regelbundet Uppdragsledaren Sprintteamet Avstämning av arbetet och planering av kommande vecka. Första dagen i varje sprint Sprintplaneringsmöte Förvaltningsgruppens ordförande Förvaltningsgruppens ordförande och Sprintteamet Planering av sprint. 9. Förslag på fortsatt utveckling Önskemål för vidare utveckling tas in och prioriteras löpande av förvaltningsgruppen.

20 Dokumentttyp Datum Utgåva Sida SYSTEMFÖRVALTNINGSPLAN P (14) Utfärdat av 10. Arbetsmodell Enligt bilaga 1.

21 Dokumenttyp Datum Utgåva Sida KRAVSPECIFIKATION (7) Dokumentansvarig Kravspecifikation Bilaga 6 1. Allmänt ID Rubrik Beskrivning 1.1 Titel <Titel på kravet eller funktionen som ska utvecklas> 1.2 Ärendenr <Ärendenummer enligt ärendehanteringssystem> 1.3 Ärendeklass <Klassning av ärende> 1.4 Titel 1.5 Avser system <Vilket system som kravet gäller för> 1.6 System- och informationsägare <Vem äger informationen och systemet> 1.7 Systemförvaltare <Vem är systemets förvaltare> 1.8 Förslagsgivare <Vem har lämnat kravet> 1.9 Förkrav <Vilka andra krav måste vara uppfyllda innan detta krav kan genomföras> 1.10 Verksamhetsnytta <Beskriv vilken verksamhetsnytta funktionen ska bidra till> 1.11 Önskad effekt <Vilken effekt den önskade funktionen ska bidra med till verksamheten> 1.12 Deadline <Reell deadline då funktionen måste vara klar för att effekten ska kunna uppnås. Kan t.ex. bero på andra skarpa deadlines för processer som systemet stödjer> 1.13 Avgränsningar <Vilka avgränsningar finns> 1.14 Övrigt 2. Godkännande ID Roller Godkännare 2.1 Produktägare <Produktägare som godkänner kravspecen enligt markering i punkt 4, Utgåvehistorik för dokumentet> 2.2 Systemutvecklare <Systemutvecklare som godkänner kravspecen enligt markering i punkt 4, Utgåvehistorik för dokumentet> 2.3 Testare <Testare som godkänner kravspecen enligt markering i punkt 4, Utgåvehistorik för dokumentet>

22 Dokumenttyp Datum Utgåva Sida KRAVSPECIFIKATION (7) Dokumentansvarig 3. Innehåll 1. Allmänt Godkännande Innehåll Utgåvehistorik för dokumentet Bilagor Beskrivning Tidsuppskattningar Användarberättelser Användarfall Skisser och hjälptexter Befintlig design Förslag på ny design Funktionella krav Icke funktionella krav Beslutstabell Testfall Testfall Testfall Utgåvehistorik för dokumentet Utgåva Datum Kommentar Godkännande 1.0 Produktägare Systemutvecklare Testare 5. Bilagor Bilaga Dokumentnamn Utgåva, datum

23 Dokumenttyp Datum Utgåva Sida KRAVSPECIFIKATION (7) Dokumentansvarig 6. Beskrivning ID Rubrik Beskrivning 6.1 Ny funktion <Ja / Nej> 6.2 Ändring av funktion <Ja / Nej> <Ange vilken funktion som ändringen avser. Beteckning nummer etc.> 6.3 Behörighet <Ange ev. behörigheter för funktionen> 6.4 Intressenter <Vilka är intressenterna> 6.5 Användare <Vilka är användarna> 6.6 Säkerhetskrav <Vilka säkerhetskrav avseende tillgänglighet av informationen> 6.7 Förutsättning för funktion 6.8 Påverkade processer/rutiner >Vilka förutsättningar måste vara uppfyllda för att funktionen ska kunna användas> <Vilka processer och rutiner påverkas av funktionen> 6.9 Begrepp - definitioner <Definiera centra begrepp för funktionen, processen, rutinerna> 6.10 Styrande riktlinjer <Ange ev. vilka styrande riktlinjer som finns> 6.11 Tidsuppskattning - utveckling <Uppskattad utvecklingstid från systemutvecklare> 6.12 Testare <Vem ska testa funktionen> 6.13 Systemberoenden <Vilka systemberoenden finns för funktionen> 6.14 Inblandade datakällor <Ange inblandade datakällor> 6.15 Tabeller och fält <Ev. inblandade tabeller och fält> 7. Tidsuppskattningar Rubrik Utvecklingstid Testtid Dokumentering Införande Beskrivning <Hur många utvecklingstimmar beräknas funktionen ta> <Hur mycket testtid inkl. tid för att ta fram testfall beräknas> <Hur mycket tid beräknas dokumenteringen av funktionen ta> <Hur mycket tid beräknas införandet av funktionen ta>

24 Dokumenttyp Datum Utgåva Sida KRAVSPECIFIKATION (7) Dokumentansvarig 8. Användarberättelser Rubrik Roll Mål Motivering Beskrivning <Vilken roll har användaren i systemet> <Som en. vill jag kunna > <Varför jag vill kunna göra den önskade handlingen> 9. Användarfall Rubrik Roll Huvudscenario Alternativt scenario 1 Alternativt scenario 2 Undantag-scenario 1 Undantag-scenario 2 Språk Hjälptexter Beskrivning <Vilken roll har användaren i systemet> <Den huvudsakliga processen som ska genomföras med funktionen, steg för steg>

25 Dokumenttyp Datum Utgåva Sida KRAVSPECIFIKATION (7) Dokumentansvarig 10. Skisser och hjälptexter 9.1 Befintlig design 9.2 Förslag på ny design Del Del Del 3

26 Dokumenttyp Datum Utgåva Sida KRAVSPECIFIKATION (7) Dokumentansvarig 10. Funktionella krav <Funktionella krav anges med krav-id> 11. Icke funktionella krav <Icke funktionella krav anges med krav-id, t.ex. driftskrav, tillgänglighetskrav, vilka enheter som ska stödjas, mm.> 12. Beslutstabell Villkor Regel 1 Regel 2 Regel 3 Regel 4 Händelse

27 Dokumenttyp Datum Utgåva Sida KRAVSPECIFIKATION (7) Dokumentansvarig 14. Testfall 14.1 Testfall 1 Rubrik Titel Förberedelser Teststeg Förväntat resultat Testdata Egenskaper Förväntat utfall Kriterier för godkänd 14.2 Testfall 2 Rubrik Titel Förberedelser Teststeg Förväntat resultat Testdata Egenskaper Förväntat utfall Kriterier för godkänd Beskrivning Beskrivning