ITS ansvar vid uppdatering

• Logga in som administratör i Limesurvey
• Svara på en enkät i LimeSurvey
• Enkätsvar exporteras till DIP.
• Svar kan hämtas ur DIP-Exporter.
• Behörighetsadministratör kan ändra behörighetsinställningar i DIP-Admin

Ditt ansvar som kund vid uppdatering

Genomför följande reflektion: ”När denna förändring kommer till PROD, kommer insamling och datauttag fortsätta att fungera som vanligt? Fungerar den uppdaterade plattformen för studiens unika behov?”

Om studieteamet inte kan svara på den frågan med de tester genomförs på STAGE så tar studien stora risker. I värsta fall kanske inga nya svar kan insamlas, databasen går sönder och all data som ligger i DIP blir förstörd. Om det scenariot innebär ett problem för studien så är det ditt ansvar att så långt som möjligt säkerställa att den kommande programuppdateringen inte orsakar problem.

ITS genomför grundläggande allmänna tester för att säkerställa plattformens integritet och vi tar backuper på insamlat material, men det är ditt ansvar att se till att just din studie kan fortsätta normalt efter programförändringen. Det är därför ITS erbjuder STAGE-miljön.

Varje studie har unika förutsättningar och DIP-teamet på ITS har inte verksamhetskunskap eller förmåga att verifiera att studiespecifikt insamlings- och datauttagsregelverk uppfylls.

Rent konkret rekommenderas att du gör följande:

• Prata med studiens teammedlemmar och be dem verifiera funktionen i STAGE-versionen av plattformen så långt som möjligt i god tid innan den skarpa driftsättningen till PROD.
  • Det kan till exempel innefatta att de viktigaste användningsfallen testas i STAGE:
    • Kan vi registrera nya användare?
    • Kan man spara svar till plattformen?
    • Kan jag administrera användare som tidigare?
    • Kan vi hämta ut svar från DIP?
    • Innehåller svaren rätt information?
    • Spara undan kopior på redan insamlat material inför PROD-releasen.

Efter att studieteamet utfört dessa tester bör du känna dig trygg med att den nya releasen fungerar för studien, – Eller- så upptäcker studieteamet ett problem, något viktigt kanske har slutat fungera, då måste du kontakta ITS och säga ”Funktion X har gått sönder, studiens integritet hotas om detta kommer till produktion, ITS måste laga felet innan vi kan produktionssätta detta!”

Studieteamet bör överväga att ta fram en intern process för hur studien ska hantera programuppdateringar, så att studieteamet har ett protokoll att följa för att verifiera studiens integritet. Den bör innehålla:

• Tester som ska utföras vid release.
• Vem som ansvarar för att testerna utförs.
• ”No-go” kriterier för produktionssättning.
• Jämför eventuella felaktigheter med nuvarande PROD-beteende. Beskriv skillnaden i PROD- och STAGE-beteende, samt vilka problem det orsakar studien.
• Vem man ska kontakta för att flagga en ”No-go” samt vad som orsakar ”No-go”-scenariot.

Syftet med programuppdateringen är att ITS vill förbättra upplevelsen för alla aktörer och ta bort felaktigheter. Det kan inte göras utan risker för pågående studier. Det är därför studiens egna release-verifiering är så viktig.