Överlämning till förvaltning

PÅBÖRJAD REVISION GODKÄND

Inledning

Syfte: Denna sida finns för att du skall få insikt i hur överlämnandet av en app till förvaltning bör gå till. Då en app skiljer sig från en webtjänst så är det viktigt att få insikt i hur även förvaltningen skiljer sig tjänsterna emellan.

Målgrupp: Beslutsfattare, uppdragsledare, projektledare, utredare.

Instruktion för användning: Använd utvärderingens verktyg; checklistor, etc. som stöd för att snabbt undersöka om initiativet är genomförbart. Observera att verktygen är ett stöd för att identifiera blockerande skäl - varje tjänst har unika egenskaper.

Påverkan av appar:

En app som anropar andra tjänster i förvaltningen kommer att ytterligare öka förvaltningsbehovet utav dessa tjänster. En app blir således inte bara ytterligare en tjänst att förvalta utan övriga tjänster måste även vara kompatibla och stabila i kombination med appen.

Exempel på områden där appar hanteras annorlunda i förvaltning:

Om appen behöver uppdateras innehåller release-cykeln följande steg

• uppdatering av koden för appen - kräver tillgång till utvecklingsverktyg i rätt version (och ej EOL)

• testa appen i tjänsten - speciell hantering krävs för att distribuera appen för test och kvalitetssäkring

• lämna appen för granskning hos den som driver app store - hantera ev anmärkningar, OBS - räkna med ca en veckas ledtid för denna cykel, beror av belastning på granskare, appens natur och komplexitet

• signera appen för publicering - kräver tillgång till Ineras utvecklings-certifikat

• publicera appen och beskriv vad som uppdaterats (release notes), ev behöver även beskrivning och bilder uppdateras

• hur når man ut till slutanvändare med den uppdaterade tjänsten? Appar kräver aktiv uppdatering!

Budgetering av uppdateringar (t ex i beredning) måste ta höjd för ovanstående release-cykel. Ovanstående lista är ytterligare insatser utöver webbappar! Det är dessutom vanligt att man uppdaterar appar minst på årlig basis, t ex för att hantera nya versioner av enheternas operativsystem (som publiceras årligen).

Delar av processen (kapitel, dokument, verktyg, praktiskt arbete, etc.) som påverkas:

Dokumentation och rutiner kring hur man ska hantera publicering, revidering och avveckling av appar i app stores behöver införas i processen.

Följande dokumentation rörande appen behöver ha producerats när förvaltningen tar emot tjänsten:

• Användardokumentation

• Supportdokumentation

• Kravspecifikation

• Förstudie och annan dokumentation som producerats under apputvecklingens löptid

• Driftdokumentation

• Systemdokumentation (SAD)

• Arkitekturella beslut (AB)

• Tjänstekontraktsbeskrivningar och beskrivning av tjänstedomänen.

• Riskanalys

• PUB-avtal

• Avtal (interna och externa)

• Juridiska  överväganden och regelverk

• Plan för breddinförande

• Affärsmodell och finansiering av förvaltningen

• Förvaltningsplan och förvaltningsspecifikation enligt pm3

  • Förvaltningsstyrning

  • Användarstöd

  • Ändringshantering

  • Daglig IT-drift och underhåll

  • Relevanta processer

• Restlista och backlogg

• Referenspiloter/referensregioner

• Användargrupper

• Testprotokoll från acceptanstest

• Testprotokoll från produktionstest med godkännande från Infrastruktur

• Utvärdering pilotdrift

• Förvaltar- och supportutbildning

• Marknadsföring och kommunikation

• Interna kontaktpersoner/uppgifter

• Kontaktpersoner/uppgifter om leverantörer

Vilka delar av detta skall återföras till beslutsstöd? (påverkan på policy, budget, etc.)

Att förvalta en ytterligare tjänst i form av en eller flera appar kommer öka resursbehovet så budget kommer att påverkas. Då Inera traditionellt sätt inte förvaltat appar så behöver det även säkerställas att adekvat kompetens finns i förvaltningen, ifall det inte finns så behöver denna kompetens införskaffas.

Ta höjd för ökad förvaltningsinsats/kostnad enligt ovan!