Ö PPEN FRÅGESTUND Adobe Connect, den 30 mars 2016

2 Dagens agenda Arbetet med tidiga lärosäten Förändringar i testverksamheten Ärenden från Jira Övriga frågor

3 Nästa öppen frågestund – den 27 april Version MAH presenteras Efter ÖF publiceras underlag

Arbetet med de tidiga lärosätena - Malin Zingmark

5 KKH Börjar mata in data i produktionsmiljön månadsskiftet april/maj Stänger befintligt system vid terminsstart i augusti Mappning av utbildningsstruktur och arbetssätt mot nya Ladok pågår

6 KMH Planerad produktionssättning slutet av 2016 Aktiviteter för att nå i mål identifierade Arbetet med integrationer påbörjat Arbete pågår med att identifiera vilka verksamhetsfrågor som måste lösas

7 MAH Planerad produktionssättning Q Prioritering av den funktionalitet som behövs för att MAH ska kunna gå igång gjord Aktiviteter för att nå i mål identifierade Arbetet med integrationer påbörjat Arbete pågår med att identifiera vilka verksamhetsfrågor som måste lösas Ett antal samarbetsforum med Ladok3-projektet igång

8 Vad jobbar produktionssättningsteamet med? Lösning av olika verksamhetsfrågor – koppling mellan professor/student, interimspersonnummer, mm Identifiera vilken grunddata/mallar som lärosätena behöver mata in i systemet Extra insatser kring registervård Upplägget vad gäller utbildning ses över och utbildningsmaterial ska tas fram Stöd vad gäller integrationer Säkerställer att nödvändiga tester görs innan produktionssättning Identifiera aktiviteter som behöver färdigställas för att nå i mål och följer upp dem tillsammans med lärosätet Planering av produktionssättningar påbörjad - tekniskt och verksamhetsmässigt. Vad behöver vara genomfört innan, hur lång nertid i nya Ladok innebär en produktionssättning

Förändringar i testverksamheten

10 Målsättning Snabbare tillgång till förbättringar i systemet Produktionsdugligt system kontinuerligt Tidig återkoppling från riktig användning

11 Process för leveranserna hittills – ex. RESULTAT 1.Utveckling i team 2.Verksamhetstest 3.Acceptanstest 4.Produktionssättningsprocess 5.Leveransen når verksamheten – RES 1.3

12 Process för leveranserna hittills – ex. RESULTAT 1.Utveckling i team 2.Verksamhetstest – rättning16 veckor 3.Acceptanstest – rättning 4.Produktionssättningsprocess 5.Leveransen når verksamheten – RES 1.3

13 Process för leveranserna hittills – ex. RESULTAT 1.Utveckling i team 2.Verksamhetstest – rättning16 veckor 3.Acceptanstest – rättning 8 veckor 4.Produktionssättningsprocess 5.Leveransen når verksamheten – RES 1.3

14 Process för leveranserna hittills – ex. RESULTAT 1.Utveckling i team 2.Verksamhetstest – rättning16 veckor 3.Acceptanstest – rättning 8 veckor 4.Produktionssättningsprocess17 veckor 5.Leveransen når verksamheten – RES 1.3

15 Vad hände sedan? Återkoppling från riktig användning RES 1.4

16 Fråga Var ni nöjda med RES 1.3? Är ni nöjda med RES 1.4?

17 Vår idé framåt (fas 1) Produktägare verifierar ändamålsenlighet under utveckling Öka testkompetens i utvecklingsteam - automatisera Verksamhetstest på plats i Malmö Användartest på plats i Malmö Återkoppling från riktig användning från tidiga lärosäten

18 Innebär också Funktionen verksamhetstest (inom projektet) avvecklas Funktionen acceptanstest (inom förvaltningen) avvecklas

19 Och… Projektet tar helhetsansvar för systemets kvalitet Lärosätena ska inte acceptanstesta

20 Varför nu? Nuvarande verksamhetstestare lämnar Lång process att komma igång med nya Tidigarelagd övergång – möjliggjord mha MAH

21 På längre sikt Jobba med kontinuerlig leverans av ny funktionalitet Återstår att konkretisera ytterligare åtgärder Vi ber att få återkomma

22 Kontinuerlig leverans - exempel SVT, Mira, Spotify, Klarna, Telia, Myndigheten för tillgängliga Media, Skatteverket…

Kravönskemål och frågor från Jira - Matz- Cajdert m.fl.

24 Först något om versioner Vi ska vara klara med version A-I när Malmö högskola går i drift I version J ligger sådant som man bedömer att MAH kan klara sig utan under en kort tid, men som ändå är prioriterade måste-krav för MAH I version V läggs sådana krav som är måste för övriga lärosäten Fler versioner kommer att tillkomma mellan J och V Krav kommer att flyttas successivt från X till J/V, även i övrigt leder förtydliganden av kravbilden till att åtgärder kontinuerligt flyttas mellan versioner

25 L3SUPPORT-2286: Skrivningspoängen behöver synas på modulerna/proven i kursen när slutbetyg sätts Jag har en examinator som sätter slutbetyg på kursen utifrån skrivningspoängen på modulerna. Skrivningspoängen syns inte utan bara betyget. Både skrivningspoäng och betyg behöver synas när slutbetyg sätts. SVAR FRÅN PROJEKTET Vi ser över resultatnoteringar i version D och stämmer av om detta är ett måste-krav för MAH. Om inte så lägger vi tillsvidare in det som ett förbättringsförslag för version V.

26 L3SUPPORT-2340: Visa både start- och slutdatum för registrering studentgränssnittet Vid demo av version B visade man att i studentgränssnittet visas endast när en kurs öppnar för registrering (om den inte öppnat ännu) Bara om kursen är öppen för registrering visas start- och slutdatum för studenten. Vi på HKR tycker att både start- och slutdatum för registrering ska visas oavsett om kursen öppnat eller inte. SVAR FRÅN PROJEKTET Anders Stenebo ska testa studentgränssnittet mot studenter för att ta reda på vilka förbättringar som bör prioriteras, sett ur deras perspektiv. Vi återkommer med besked angående denna specifika åtgärd efter detta.

27 L3SUPPORT-2322 Datum för läsår måste kunna ändras av lärosätena (periodtyp) Om man väljer den fördefinierade typen termin så kan lärosätet själv ändra datum till att passa sina terminstider. Om man väljer den fördefinierade typen läsår så kan lärosätet inte ange datum för start och slut, och datumen är satta till kalenderterminer. På LU vill vi kunna ange att läsåret är samma som höst+vårtermin, dvs ungefär 1/9-31/8 (exakta datum varierar mellan åren). SVAR FRÅN PROJEKTET Vi utreder möjligheten att ändra periodtyp för läsår från nationellt fastställd till nationellt baserad under version D. Åtgärden placeras dock troligen i version X tillsvidare.

28 L3SUPPORT-2331: Om man kopplar attestant till kurs ska kopplingen gälla för samtliga kursversioner Om man går in på Förbereda kurs måste man alltid välja kursversion, och rollen som attestant är alltid knuten till version av kursen. Detta är inte bra. Om man vill begränsa attestantens behörighet är det bättre att använda kurstillfälle. Om man däremot vill ge attestanten rätt till hela kursen borde man inte tvingas att ange henne/honom på varje version av kursen som finns (det varierar väldigt mycket hur många versioner det finns). Glömmer man detta kan det leda till att man inte kan attestera vissa studenter, vilket kan vara svårt för attestanten att förstå. Alltså, ändra så att "Förbereda kurs" innebär just det som står i rubriken. Om detta inte går att fixa, ändra i så fall rubriken till "Förbereda kursversion", så att det stämmer med verkligheten.

29 L3SUPPORT-2331: Om man kopplar attestant till kurs ska kopplingen gälla för samtliga kursversioner SVAR FRÅN PROJEKTET Självklart ska namnet på en funktion/flik ska stämma med underliggande funktionalitet. Versioner av kurs hanteras i version G och i nuläget kan vi inte avgöra hur vi ska lösa hela problemet. Vi tar med oss synpunkten i kommande utvecklingsarbete.

30 L3SUPPORT-2336: Rapportera aktivitet och försörjning via studentgränssnittet? Vi har många doktorander som varje termin ska rapportera in aktivitet och försörjning. Idag sker det via en blankett i pdf eller en förifylld blankett som skrivs ut via nuvarande Ladok. En administratör lägger därefter in uppgiften i systemet. Hur kommer det att fungera i nya Ladok? Kommer en doktorand att själv kunna rapportera aktivitet och försörjning via studentgränssnittet? Eller kommer det att finnas möjlighet för en administratör att skapa förifyllda blanketter via systemet i t.ex. pdf? SVAR FRÅN PROJEKTET Forskarnivån gås igenom i version D. Ett alternativ är att doktoranderna successivt registrerar sig på kurser/motsvarande, vilket i sin tur ger grund för beräkning av studieaktiviteten. Även ovanstående önskemål bör vi stödja i någon form, placeras i version X.

31 L3SUPPORT-2301: Frågor om funktioner i Ladok - Rättelse av betyg via studentvyn? Kommer det att gå att rätta betyg genom att gå in på studenten? Idag är funktionen endast tillgänglig via kursen (vad vi kunnat se)? SVAR FRÅN PROJEKTET Funktionaliteten bör finnas, i nuläget är det dock osäkert om vi tar det i version I, J eller V.

32 L3SUPPORT-2243: Vilka data är tvingande och när - mellan Ladok3, NyA, lokal utbildningsdatabas Vi har funderingar kring hur "trafiken" mellan den lokala utbildningsdatabasen, Ladok3, NyA och studera.nu ska fungera. Vilken grad av flexibilitet kommer att finnas i Ladok3 vad gäller mottagning av data från annat system och för leverans till NyA? Det i förhållande till studera.nu? Hur pass kompletta måste uppgifterna vara från början och/eller vilka möjligheter finns eller kommer att finnas till komplettering eller ändring av data och när i tiden? Och i vilket läge kan man ändra eller inte ändra data?

33 L3SUPPORT-2243: Vilka data är tvingande och när - mellan Ladok3, NyA, lokal utb-db SVAR FRÅN PROJEKTET Ladok kommer att kunna fungera som ”nav” för överföringar i enlighet med Emil-schemat. Nödvändiga krav för att uppfylla det ställs upp i relevanta nationella utbildningsmallar. Lärosätena kan inom givna ramar styra när olika attribut ska vara på plats i de lokala mallarna. Utbildningsutbudet skickas vidare från Ladok genom särskilt kommando. Ändringar efter publicering till NyA måste kunna hanteras. Delvis kan det lösas genom att vissa attribut läggs utanför statushanteringen. En mer grundlig genomgång är lämplig att göra efter version E när vi tar oss an helheten för detta.

34 L3SUPPORT-2324: Frågor om funktioner i Ladok - uppföljning I detaljfilen (exportera underlag) finns två datum. Bägge datumen har nu samma värde när det hämtas från nuvarande Ladok. Tycker att det är mer rimligt att beslutsdatum sätts till nuvarande idatum, det ligger säkert mer nära i tid till beslutsdatumet än examinationsdatumet (provdatum).

35 L3SUPPORT-2324: Frågor om funktioner i Ladok - uppföljning SVAR FRÅN PROJEKTET Beslutsdatumet är, just nu i Ladok3 detsamma som attestdatum, eftersom beslutet sker i det ögonblick examinator attesterar. (Vi stödjer än så länge bara ett digitalt flöde.) Vi har i modellen tagit höjd för att attestdatum är skilt från när beslutet fattas och att det läggs in i Ladok via attestering av annan än examinator, dock har vi inte prioriterat stöd för den manuella processen i nuläget, vilket gör att beslutsdatum förnärvarande känns överflödigt. Eftersom vi i nuvarande Ladok endast talar om (betygs)datum så konverteras det befintliga betygsdatumet till båda posterna. Att istället använda inläggningsdatum är mindre lämpligt då detta endast återspeglar när det lagrades i Ladok. Vi utreder om det är möjligt och bättre att lämna beslutsdatum blankt i konverteringen.

36 L3SUPPORT-2051: Det ska inte vara möjligt att rapportera in betyg på studenten Förväntat resultat: Vid inrapportering av betyg på student som saknar terminsregistrering ska det inte vara möjligt att rapportera in betyg på studenten. Utfall: Vid inrapportering fås ett valideringsfel i samband med attestering av betyg efter återautensiering. Det är förstås korrekt att det bör ske en validering i samband med attesttillfället, dock undrar vi om man övervägt om det bör finnas en varning eller validering redan vid inrapportering av betyget? Man blir stoppad väldigt sent.

37 L3SUPPORT-2051: Det ska inte vara möjligt att rapportera in betyg på studenten SVAR FRÅN PROJEKTET Detta rör resultatleveransen (berör ej slutleveransen) I attestera-vyn ser man nu för vilken student det finns hinder mot resultatrapportering. Att åtgärda enligt önskemålet och lägga en kontroll i rapportera-vyn skulle i dagsläget innebära att man inte kan klarmarkera, men man skulle ändå inte ha stöd för att visa vilken student som har hinder. Att även förbättra detta är tyvärr en mer omfattande åtgärd och borde då förmodligen inkludera fler hinder.

38 L3SUPPORT-2284: Stående beställning på resultatverifikat Önskemål om att man kan göra en stående beställning på uttag av verifikaten. Känns lite pyssligt att man ska komma ihåg att manuellt köra dessa. SVAR FRÅN PROJEKTET Rimligt förbättringsönskemål som vi placerar i version X, bör.

39 L3SUPPORT-2138: Examinator och examinators titel Jag skriver med anledning av informationen som kommit fram kring att examinator och examinators titel inte lagras vid rapportering av resultat. Detta försvårar för oss då vi inte kan slutrapportera någon kurs för tekniska högskolan. Hur ligger denna funktionalitet i prioritet för slutleverans? Kommer vi kunna lagra examinator och examinators titel vid rapportering av resultat för att kunna skriva ut detta på examensbevis? SVAR FRÅN PROJEKTET I version C kan man välja att redovisa examinator, inkluderar i nuläget inte examinators titel. I version D inkluderas examinators titel om det är viktigt för MAH, annars senare.

Övriga frågor?