1(26) PROJEKTPLAN ivis innovativt Verksamhetssystem I Skolan Datum Version Namn Roll/befattning Kommentar 20150121 1.0 Hillar Loor Projektledare Komplett med forskning 20150113 0.95 Hillar Loor Projektledare Med sammanfattning 20150105 0.9 Hillar Loor Projektledare Sammanskrivning 20150102 0.85 Lotta Ruderfors Projektkoordinator Kompletteringar, kommunperspektiv 0.8 Hillar Loor Projektledare Start plan Projektgruppens operativa plan för hur projektet ska organiseras och genomföras. Planen ska godkännas av uppdragsgivaren innan projektet startas. Ger projektets intressenter en gemensam bild av projektet.
2(26) Innehållsförteckning 1Sammanfattning... 3 2Bakgrund, syfte och mål... 4 2.1Bakgrundsbeskrivning... 4 2.2 Syfte... 4 2.3 Mål... 5 2.3.1Långsiktigt mål... 5 2.3.2Kortsiktigt mål - teknik... 6 2.3.3Kortsiktigt mål presentera ny filosofi... 7 2.4Förväntad nytta/resultat... 7 2.4.1 Skolan... 7 2.4.2Nya aktörer... 7 2.4.3Generellt... 7 2.4.4Kostnader... 8 2.5Mina meddelanden... 8 2.6Öppna data... 8 2.6.1Plattformen... 8 2.6.2Öppna data... 8 3Metod och genomförande... 9 3.1Övergripande tekniska principer... 9 3.1.1Initialt principer... 9 3.1.2 Miljö... 9 3.1.3 Databas... 9 3.1.4Rollstyrning... 9 3.1.5Standarder... 9 3.2Metod och riskhantering... 9 3.2.1eDelegationens vägledning... 9 3.2.2Utvecklingsmetod...10 3.2.3Forskning...10 3.2.4Teknisk metod...10 3.2.5Implementering... 11 3.2.6Riskhantering... 11 3.3Förankring och kvalitetssäkring... 11 3.4Avgränsningar... 12 3.5Förutsättningar och krav... 12 3.5.1Samverkan med målgruppen...12 3.5.2Marknadsföring...12 4Leveransleverabler... 13 4.1Programvara... 13 4.1.1Grundläggande plattform...13 4.1.2Grundfunktioner...13 4.1.3Modul 1 skolskjuts...13 4.1.4Modul 2 ej beslutad...13 4.2Tester/driftsättning i verklig miljö... 14 4.2.1Implementering i skolan...14 4.2.2Uppsättning av etjänst...14 4.2.3 Beslut...14 4.2.4Utskick av beslut...14 4.2.5Mobil-app...14 4.2.6Parallellt med befintligt system...14 4.3Community... 14 4.4Modeller kring Eko-system... 14 4.5Marknadsföring... 15 5Nulägesanalys och intressenter... 15 5.1SWOT-analys... 15 5.1.1Styrkor (S)...15 5.1.2Svagheter (W)...15
5.1.3Möjligheter (O)...15 5.1.4 Hot (T)...15 5.2Intresentanalys... 15 5.2.1 Sambruk...15 5.2.2Konsulter...15 5.2.3Skolor/kommuner...15 5.2.4 SKL...15 5.2.5Andra leverantörer...16 6Tidsplan och aktiviteter... 16 6.1Milstolpeplan... 16 6.2Aktivitetsplan... 16 6.3Tidsplan... 16 7Organisation och bemanning... 16 7.1Styrgrupp... 16 7.2Referensgrupp... 16 7.3Projektgrupp... 16 7.4Roller, ansvar och befogenheter... 17 7.4.1Projektledare...17 7.4.2Projektkoordinatör...17 7.4.3Teknisk projektledare...17 7.4.4Löpande organisatorisk beslut...17 7.4.5Löpande tekniska beslut...17 7.4.6Styrgruppsmedlem...17 7.4.7Referensgruppsmedlem...17 8Budget - finansieringsplan... 17 8.1Sambruk... 17 8.2imCode... 18 9Kommunikation och kvalitetssäkring... 19 9.1Rapporter och dokumentation... 19 9.2Ändringshantering... 19 9.2.1Ändringslogg...19 9.2.2Protokoll...19 10Riskanalys och riskhanteringsplan... 19 10.1Samverkan... 19 10.2Avhopp från skolor... 19 10.3Långa avtalstider... 20 11Övrigt... 20 11.1Bilaga 1 Aktivitetsplan... 20 11.2Bilaga 2 VINNOVA ansökan... 20 3(26)
4(26) 1 Sammanfattning ivis innovativt Verksamhetsystem i Skolan är ett VINNOVA-finansierat projekt som vill skapa grundläggande förutsättningar för den svenska skolans digitalisering. ivis vill göra det möjligt för den svenska skolan att digtaliseras snabbare och mer innovativt. Detta måste ske i en samverkan mellan teknikutvecklare och målgrupperna lärare, elever, föräldrar och personal. Projektets avsikt är att bygga dels en grundläggande plattform med personregister, autentisering och säkerhet, dels 2 tjänster (dvs 2 moduler) som ett första steg till en komplett skolplattform. Projektet syftar till att ge skolan direkt och fullständig kontroll över sin egen IT-infrastruktur, genom: Öppenhet - plattformen byggs som ett öppet system Modularitet - alla användarvyer och den mesta logiken byggs i mindre, avgränsade, funktionella moduler som ligger utanför plattformen. Dessa kan skapas, förändras tas bort utan att den grundläggande plattformen behöver modifieras. Mobilitet - för användning via mobiler / plattor. Molnbaserade tjänster - ger högre stabilitet, tillgänglighet och flexibilitet. Projektet vill också skapa en möjlighet för nya utvecklargrupper som lärare/elever/föräldrar och nya leverantörer att direkt skapa funktionalitet som använder plattformens data - en miljö för användardriven utveckling. Projektet genomförs efter att Sambruk under många år hört representanter för den svenska skolan och offentlig sektor beskriva stora problem med sina IT-baserade verksamhetssystem. Dessa beskrivs som omoderna, föråldrade, inlåsta, svåra att förändra, kan inte samverka med andra system m m. I en rapport från Konkurrensverket bekräftas bilden. De pekar på att inlåsningseffekter skapar en situation där det är svårt för offentlig sektor att byta leverantörer. Kommuner hamnar ofta i en situation där leverantörer, så snart systemen är installerade, får ett de facto-monopol. Vilket i sin tur orsakar instängda system, långsam utveckling och onödigt höga kostnader.
5(26) 2 Bakgrund, syfte och mål 2.1 Bakgrundsbeskrivning Representanter för den svenska skolan och offentlig sektor har länge beskrivit stora problem med sina IT-baserade verksamhetssystem. Omoderna, föråldrade, inlåsta, svåra att förändra, kan inte samverka med andra system, är några av problemen. Konkurrensverket visar tydligt situationens allvar i en studie av Jur Dr Richard Wessman. Bl a pekar han på att inlåsningseffekter skapar en situation där det är svårt för offentlig sektor att byta leverantör och att kommuner ofta hamnar i en situation där leverantörer, så snart systemen är installerade, får ett de facto-monopol. (Utredning "Upphandling av IT inlåsningseffekter och möjligheter - Uppdragsforskningsrapport 2013:2", Konkurrensverket) Alla ambitioner att öka hastigheten i svensk skolas digitalisering, punkteras just nu effektivt av brister på interoperabilitet, avsaknad av användarcentrerad utveckling och kraftiga både juridiska och tekniska inlåsningseffekter. 2.2 Syfte Projektet vill skapa förutsättningar för en helt digitaliserad skola genom införande av en öppen, grundläggande plattform (se punkt 5 nedan). Plattformen är tänkt att utvecklas till en behållare för all administrativ skolinformation, dvs t ex elev-, vårdnadshavare- och personalregister, klasser, grupper, skolskjutsar, tider, scheman m m. Det avgörande kännetecknet är att plattformens kärna är öppen och inte går att låsa in varken tekniskt eller avtalsmässigt. Projektet syftar till att ge skolan direkt och fullständig kontroll över sin egen IT-infrastruktur. ivis kommer att garantera att olika system kan samverka genom att all data finns samlad på ett ställe. ivis blir en infrastruktur, basinformationen för all verksamhet mot vilken övriga system, som t ex lärplattformar, schemaläggningsystem etc ska kunna arbeta och hämta och lämna relevant data. Projektet vill också skapa en möjlighet för nya utvecklargrupper som lärare/elever/föräldrar och nya leverantörer att direkt skapa funktionalitet som använder plattformens data - en miljö för användardriven utveckling. 2.3 Mål 2.3.1 Långsiktigt mål Skapa en helt öppen grundläggande plattform som bas för skolans digitalisering. ivis är ett Öppet System som använder öppna standarder, öppna och väl dokumenterade API:er (API = Application Programing Interface = den tekniska kontaktpunkt där man kan hämta och lämna data från/till systemet), har öppen dokumentation, använder öppna databaser, byggs i öppen källkod,
6(26) behöver inga proprietära delar för att fungera. I bilden ovan visas principlösningen för ivis. Plattformen (1) innehåller en databas med elevregister och andra relevanta data, viss logik och säkerhet. Modulerna (2-5) är exempel på tillkommande applikationer med olika accessvyer (t ex mobiltelefon, ipad, webb) där data kan visas eller förändras. Kommunikation sker via standardiserade, öppna API:er, även med andra plattformar (7). Eftersom API-standarden är fastlagd, kan i princip vem som helst kommunicera mot plattformen (1). Med tiden, när skolan finner nya behov, kan man utveckla fler moduler som svarar mot behoven. Projektet syfte, att ge skolan direkt och fullständig kontroll över sin egen ITinfrastruktur, kan uppnås genom några enkla grundprinciper: Öppenhet plattformen byggs som ett öppet system. Modularitet att bygga mindre, avgränsade, funktionella moduler som öppet och standardiserat kan kommunicera med övriga delar inom infrastrukturen dessa kan byggas av många leverantörer och även lärare, elever, föräldrar etc. Mobilitet en stor del av dagens användare använder ITbaserade lösningar via mobila enheter. Detta är särskilt tydligt i skolan, där endast en mindre andel (främst kanslipersonal) är stationära i en reguljär kontorsmiljö. Molnbaserade tjänster och system trenden att flytta system från lokala installationer och driftscentraler till s k molnbaserade tjänster är stadigt och kraftigt tilltagande. Här finns stora vinster även för skolan, i form av högre stabilitet, tillgänglighet och flexibilitet. 2.3.2 Kortsiktigt mål - teknik Projektet avser att skapa en fullt fungerande grundläggande plattform med basdata och säkerhet samt två grundläggande funktioner (moduler) för skarp anvädning i några skolor. Basdata innebär att plattformen redan i första versionen kommer att innehålla personregister över: elever lärare
7(26) vårdnadshavare administrativ personal
8(26) Med säkerhet avser vi principer som måste implementeras för att uppfylla PUL, ge grundläggande integritet och datasäkerhet. Här handlar det i första hand om att skapa principer för hur olika externa aktörer ska kunna anropa data de har rätt att ta del av, utan att annan data visas eller förändras. Den första modulen som tillverkas (se nedan punkt 16), kommer utöver basdata, att innehålla nödvändig data för att hantera skolskjutsar t ex: Ansökningsmöjligheter via webb (etjänst) Registrering av ansökningar Beslutsförfarande Beslutsmeddelanden Skolskjutsrutter och tider Den andra modulen är ännu inte definierad (se nedan punkt 17) 2.3.3 Kortsiktigt mål presentera ny filosofi IVIS-projektet ska sprida kunskap om filosofin bakom projektet med ett helt öppet förhållningssätt. 2.4 Förväntad nytta/resultat 2.4.1 Skolan Vi förväntar oss att accelerera skolans digitalisering ge skolan direkt och fullständig kontroll över sin egen ITinfrastruktur. skapa grunden till en bred flora av kommande modulära verksamhetssystem. nya sätt att lära kommer att växa fram, baserat på utveckling från oväntade nya utvecklargrupper, t ex föräldrar, elever, lärare skapa goda förutsättningar för interoperabilitet med andra system framväxt av standarder (en konsekvens av API-modellen - se nedan) 2.4.2 Nya aktörer Dagens skola är eftersatt i sin digitala utveckling inte minst därför att det finns för få aktörer som levererar till den svenska skolmarkanden. Med fler aktörer ökar utvecklingshastigheten. Vi förväntar oss fler aktörer inom skolan, eftersom det inte krävs höga ingångströsklar för att utveckla eller implementera. Att öka möjligheterna för SME- och mikroföretag att bidra till utvecklingen, utan att detta kan stoppas av etablerade leverantörer tillväxt hos kommersiella svenska aktörer inom digitala verktyg för lärande, eftersom juridiska och tekniska trösklar för utveckling sänks
9(26) att involvera (inte minst unga) medborgare genom att skapa förutsättningar för en användardriven utveckling 2.4.3 Generellt Projektets modell kan återanvändas i de flesta verksamheter som finns inom offentlig sektor. Den kan återanvändas t ex för läromedel/lärplattformar som skapas av olika leverantörer, för hantering av teniska ärenden som bygglov och många andra verksamheter också i helt nya system som ännu inte konstruerats. Det blir lättare att skapa fler IT-lösningar, eftersom modellen med öppenhet ger lägre kostnader och enklare hantering Projektet kan visa en tydlig väg för att öka innovationshastigheten och förändra den teknisk/kommersiella spelplanen bort från de facto oligopol och inlåsningar (enligt utredning från Konkurrensverket se punkt 5) 2.4.4 Kostnader Projektet förflyttar kostnader från: leverantörsfokuserade affärsmodeller (dvs att leverantörerna försöker maximera intäkter genom att inte utveckla ny kod) drift och förvaltning av IT-system proprietära och kostnadsdrivande integrationslösningar till flexibilitet användardriven innovation mångfald med flera, nya leverantörer) samverkande affärsmodeller där kostnader fördelas över flera parter och där offentlig sektor tillsammans har inflytande över utvecklingen 2.5 Mina meddelanden I projektets förlängning ingår en koppling till mina meddelanden som en möjlighet. Detta ligger i nästa fas (Del -3) av projektet, efter att 2 tjänster har driftsats. 2.6 Öppna data 2.6.1 Plattformen IVIS bygger på principen om Öppna verksamhetsdata - ett öppet system som använder öppna standarder, öppna och väl dokumenterade API:er, har öppen dokumentation, använder öppna databaser, byggs i öppen källkod, fungerar utan proprietära delar. Plattformen innehåller databas med elevregister och andra relevanta data, viss logik och säkerhet. Modulerna är tillkommande applikationer med olika vyer för olika kanaler (mobilt, webb, klient etc) där data kan visas eller förändras. Kommunikation sker via standardiserade, öppna API:er, även med
10(26) andra plattformar. Eftersom API-standarden blir fastlagd, kan i princip vem som helst utveckla mot plattformen. Kort sagt projektets princip bygger på att alla data som inte är stängd av integritets- och/eller säkerhetsskäl, skall vara öppet åtkomligt. 2.6.2 Öppna data Även om realtidsdata är åtkomligt för auktoriserade personer, finns det troligen både ett behov och en möjlighet att skapa uttag ur registren som mer traditionell Öppna data. Projektet avser att med kommunerna diskutera vad som kan vara aktuellt som Öppna data för fritt uttag. Diskussioner behöver föras med inblandade kommuner och med de parter som redan har erfarenhet av Öppna data, som t ex Örebro kommun.
11(26) 3 Metod och genomförande 3.1 Övergripande tekniska principer 3.1.1 Initialt principer Leveransen skall vara byggd på: öppen källkod öppna databaser tillgängliga öppna standarder tillkommande öppna standarder/kommunikationsprinciper 3.1.2 Miljö Som hypotes avser projektet bygga systemet i java och med mysql som databas. Denna hypotes prövas i januari tillsammans med konsulter inom programutveckling med öppen källkod och agil utveckling. Den kommande driftsmiljön är: Valfritt Linux eller Windows OS, Apache, Tomcat, Java, mysql databas. 3.1.3 Databas I öppenhetsprincipen ingår att databasen hanteras via Hibernate, vilket öppnar för användning av andra databaser, både öppna och slutna. 3.1.4 Rollstyrning Systemet är rollstyrt där rättigheter för läs- och skrivaccess sätts av mappningar mellan roller och de olika API-rutinerna. 3.1.5 Standarder Systemet ansluter till SAML2 vilket ger möjlighet till eid/mobilt bankid i enlighet med edelegationens anvisningar. Systemet ansluts till federerad inloggning via Skolfederationen. Systemet använder i så hög grad som möjligt tillgängliga standarder, t ex TK450 samt de standarder som f n arbetas fram genom Sambruk i samarbete med andra leverantörer. I den mån det inte finns tillgängliga standarder, tar projektet fram egna modeller, som är fria att återanvändas av andra parter, 3.2 Metod och riskhantering 3.2.1 edelegationens vägledning edelegationen har publicerat Vägledning för Digital samverkan v 4.0 2014-12-17. Vägledningen är skriven för samverkan mellan olika myndigheters digitala tjänster. Den är relevant för projektet dels genom att projektet i sin förlängning kan visa sig kräva samverkan mellan olika myndigheters tjänster, dels genom att projektet också starkt kopplar användaren till en livshändelse skola. I likhet med edelegationen anser ivis-projektet att det är nödvändigt att bygga upp digital samverkan på ett teknikneutralt sätt genom att fokusera
12(26) på verksamhetsprocesser, information och tjänster i stället för respektive aktörs interna tekniklösningar. Projektet kommer därför att i relevanta delar utgå ifrån edelegationens vägledning. 3.2.2 Utvecklingsmetod Projeketet styrs av en styrgrupp med tillkopplad referensgrupp. Styrgruppen utgörs av representanter för Sambruk, imcode Partner AB samt ingående kommuner. Strygruppen sammanträder på distans ca en gång i månaden och följer och styr projektets utveckling. Projektets referensgrupp består av ett antal personer från i första hand inblandade kommuner, som ger nödvändig information för projektets utveckling. Ingående referenspersoner varierar över tiden, beroende av projektets faser och det som krävs i respektive utvecklingsfas. Referensgruppen svarar också för att förmedla kontakt med kunnig personal inom respektive kommun (se vidare punkt 14 och 17 nedan). Både styrgrupp och referensgrupp kommer att ha ett avgörande inflytande över projektets utveckling, genom att bägge representerar "verkligheten", den miljö där systemet i slutändan ska användas. När tillräckligt mycket programkod tagits fram kommer kommunerna att erbjudas testa den utveckling som skett (se punkt 17) 3.2.3 Forskning Till projektets kopplas 2 forskare/forskningsgrupper: Högskolan i Skövde Utarbetar en modell för hur olika system och aktörer ska kunna interagera och utvecklas öppet och tillsammans. Dvs definierar ett IT-ekosystem med öppen interoperabilitet, med bas i ivis. Uppsala Universitet Medverka vid modelleringen av systemet, för att beakta maximal öppenhet. 3.2.4 Teknisk metod Projektet genomförs som ett "traditionellt" open source project med ett tillkopplat OS-community. Detta innebär följande: All programkod och dokumentation publiceras fritt Projektets utveckling styrs av projektgruppen Grundläggande utveckling genomförs inom projektet Andra aktörer ges möjlighet att bidra i utvecklingen både med förbättring av kod och med utveckling av nya moduler. Arbetet genomförs med iterativ metodik All publicering sker på GitHub Detta innebär att en del av projektets interna resureser kommer att läggas på att styra ivis communityt. Community-tanken är förhållandevis ny inom kommunal utveckling. Den innebär att vem som helst kan få inflytande över utvecklingen, baserat på
13(26) aktivitet och kunskap inom områden som verskamhet, benämningar, processer, programmering, testning etc. Dvs den som vill är inbjuden att vara med och bidra till utvecklingen på olika sätt. Om någon väljer att bidra med sin kunskap (t ex om verksamhet) kan projektet undvika en del fällor, om någon väljer att förändra benämningar blir programvaran tydligare eller om en utvecklare väljer att programmera, kan denne både bidra till utvecklingen och samtidigt få en djupare insikt i programvarans bakomliggande struktur. Fördelarna för kommuner som väljer att engagera sig är uppenbara en direktkanal till pågående utveckling med möjlighet att bättre förstå vad som utvecklas, vilka för-/mackdelar utvecklingen har och på vilket sätt den kan integreras i den egna verksamheten. Prioritering av projektets tekniska utveckling sker i följande ordning: 1. grundläggande teknik/miljö 2. databskopplingar 3. säkerhetsimplementering i API 4. personregister 5. modul 1 hanteringar av skolskjutsverksamhet 6. driftsättning skarp drift 7. modul 2 ännu inte definierad, defineras tillsammans med ingående kommuner under Q1 2015. 8. driftsättning skarp drift 3.2.5 Implementering I punkt 17 nedan beskrivs hur implementering av ivis slutresultat ska kunna ske. Det är väsentligt att medverkande kommuner ger projektet den tid som krävs. 3.2.6 Riskhantering Projektets risker är inte i första hand tekniska utan organisatoriska och kommersiella. Projektet kan enbart lyckas genom en nära samverkan med skolan. Det innebär att om skolor/kommuner inte ställer upp med personal är risken stor för att projektets slutresultat inte är tillräckligt förankrat och användarorienterat. Detta måste hanteras genom i första hand föreningen Sambruks rutiner och kontaktytor. De kommersiella effekterna kan vli dubbla, både ett kraftigt motstånd från etablerade leverantörer, och en medverkan från andra som ser en ny marknadsmöjlighet. Motståndet kan enbart hanteras genom ett långsiktigt informationsarbete och genom strategin att i första hand leverera tjänster som inte finns i de andra plattformarna, för att sedan när ivis finns hos kommunerna, introducera öppna tjänster som redan finns hos kommunerna genom andra leverantörer. På så sätt kan man skapa förtroende för en ny plattform och bryta oligopolet.
14(26) 3.3 Förankring och kvalitetssäkring Förankring sker genom ett antal olika åtgärder: styrgruppen referensgruppen inblandade referenspersoner föreläsningar på konferenser av typen Sundsvall 42, Offentliga rummet, Sambruks höst/vårkonf, etc. Det finns en webbplats med all information, nyheter etc. Samverkan med liknande projekt t ex inom SKL. Kvalitetssäkring sker i första hand genom att: forskare följer projektet all dokumentation är öppen på webbplatsen alla använda standarder redovisas på webbplatsen community-tänkandet finns närvarande (se punkt 18) verkliga tester sker när systemet går live återkoppling från detta modifierar systemet I en senare fas skall också pressen bearbetas för att visa de stora fördelar modellen med öppenhet har. 3.4 Avgränsningar Projektet kommer inte att leverera ett fullt fungerande skoladministrativt system, utan hålla sig till grundläggande komponenter med 2 huvudfunktioner. Avsikten är att i nästa fas (ivis del 3) utveckla tillkommande delar av det skoladministrativa systemet. 3.5 Förutsättningar och krav 3.5.1 Samverkan med målgruppen Medverkande i styrgruppen förväntas vara med på ett 2 tim möte i månaden, samt därutöver lägga några timmar på att förmedla kontakter till andra, finna ev referenspersoner för specifika frågor, samt följa projektets dokumentation. Referensgruppens medverkande är olika personer i olika faser. Generellt räknar vi med en årsinsats på ca 2 mandagar, fördelade på några tillfällen. Därutöver kommer det att behövas möten för specifika ändamål, t ex input från utvalda kontaktpersoner som lärare, eller administrativ personal. Dessa möten handlar i hög grad om att få svar på frågor om t ex, administrativa rutiner, lärares hantering av viss information, användarnas synpunkter på utveckling etc. Projektet kommer också att behöva personer i målgruppen som är beredda att prova systemet i sin ordinarie verksamhet. Det innebär i sak ingen större extrabelastning tidsmässigt, men väl ett behov av att lära sig förstå "nymodigheterna".
15(26) Beäknad tidsåtgång för en sådan person är 8-16 timmar dvs 1-2 dagar för projektperioden och ämnesområde. En person kan fylla flera ämnesområden á 1-2 dagar. 3.5.2 Marknadsföring En stor del av projektets framgång är beroende av att marknadsföringen av principer och utvecklingsmodell blir framgångsrik. Det är väsentligt att bredda förståelsen för att det är möjligt att minska inlåsningseffekter inom offentlig sektors IT-användning genom projektets metodik. Det är också väsentligt att visa hur man genom öppenhet kan accelerera utvecklingshastighet och skapa en bredare utvecklingsgrogrund för andra aktörer, både kommersiella företag och enskilda grupper som elever och lärare. Att långsiktigt motverka oligopol är en väsentlig del av projektet.
16(26) 4 Leveransleverabler 4.1 Programvara 4.1.1 Grundläggande plattform En grundläggande plattform med databas, databaskopplingar och APIer där all funktionalitet ska finnas åtkomlig. (Beskriv i efterföljande punkter) Systemets klientapplikationer/moduler byggs helt utifrån användarnas behov och måste svara mot befintliga behov och nuvarande hantering av data. 4.1.2 Grundfunktioner databas databaskopplingar/connection pool API eri json- alternativt XML-format säkerhetsfunktionalitet cachehantering för hastighetsoptimering personregister rutiner och funktioner för PUL, hantering av integritet sekretesshantering inloggning via mobilt bankid/elegitimationsnämden inloggning via skolfederationen) 4.1.3 Modul 1 skolskjuts En utveckling av en befintlig modul med ett komplett flöde omfattande kopplingar till register med uppgifter om elev och vårdnadshavare ansökan (etjänst via webb) etjänsten kopplas med fördel via t ex Open eplatform som utvecklats av 5 kommuner i Västernorrland under ledning av Sundsvall. administration/hantering av ansökan beslut beslutsbesked busslinjer kopplingar till elevens adresser visning på karta mobil-app till eleven
17(26) 4.1.4 4.1.5 Modul 2 ej beslutad Modulens funktionalitet kommer att arbetas fram under Q1 2015 smat beslutas under Q2 2015, tillsammans med representanter för kommunerna. Beslutet tas på följande principer: en funktionalitet som inte f n ingår i någon av de befintliga plattformarna en funktionalitet som stödjer en lagstadgad rutin/hantering en funktionalitet som kräver tillgång till personregister (elever, vårdnadshavare, lärare, personal) 4.2 Tester/driftsättning i verklig miljö De utvecklade modulerna sätts i drift i testmiljöer i några skolor, med skarpa användare. Nedan använder vi skolskjutsmodulen som exempel- 4.2.1 Implementering i skolan Implementering av modulen i några specifika skolor. Projektet står för drift, utbildninga av användare och implementeringsarbetet. Skolan förväntas leverera underlag för personregistret, t ex genom utkörningar i excelformat. Projektet skriver texter, e-postmeddelanden och all annan kommunikationsdialog. Skolan ger input till dialogen. 4.2.2 Uppsättning av etjänst Projektet sätter upp en etjänst för att vårdnadshavare ska kunna ansöka om tjänsten. Skolan länkar till etjänsten från sin hemsida. All data lagras i ivis. 4.2.3 Beslut Skolan använder underlaget från ivis för att ta beslut om vilka som får tillgång till tjänsten. Resultatet lagras i plattformen. 4.2.4 Utskick av beslut Utskick av beslut sker genom e-tjänsten. 4.2.5 Mobil-app Alla elever som har rätt till skolskjuts ges en möjlighet att hämta en mobilapp med skolskjutsinformation, som visar var bussarna går,och när. Förutsättning för detta är att kommunen/skolan tillhandahåller skolskjutsinformationen till projektet. 4.2.6 Parallellt med befintligt system När projektet introducerar tjänsten de första gångerna, kommer det troligen att finnas fel i tjänsten. Det är däför viktigt att skolan fortsätter med sin manuella hantering av besluten på samma sätt som tidigare, ända till tjänsten kan betraktas som felfri.
18(26) 4.3 Community Uppbyggnad av ett ivis community, där deltagande är fritt för olika intressenter. Communityt är inte beslutande, utan rådgivande och "medarbetande". 4.4 Modeller kring Eko-system Genom forskarinsats tas en första modell fram för ett IT-ekosystem med öppen interoperabilitet, med bas i ivis. 4.5 Marknadsföring Uppbyggnad av en webbplats med beskrivning av projektet, filosofin bakom och möjlighet att utbyta information för olika aktörer, t ex om standarder. Deltagande i olika former av möten, konferenser och diskussioner för att främja projektets förankring.
19(26) 5 Nulägesanalys och intressenter 5.1 SWOT-analys 5.1.1 Styrkor (S) stor kunskap inom Sambruk om problemställningarna uppenbart intresse för aktiv medverkan från kommuner leverantör med god kunskap om öppen källkod och offentlig sektor inblandade konsulter och personal ytterst kompetenta inom området 5.1.2 Svagheter (W) svårt bedöma tidsåtgång och därmed nödvändiga resurser 5.1.3 Möjligheter (O) stort uttalat behov av öppenhet i kommunerna det finns kommuner som vill medverka och hjälpa till 5.1.4 Hot (T) Svårt att hitta samverkande skolor, vilket kan försena projektet. Nuvarande oligopolstrukturer och leverantörer lär göra motstånd Utveckling inom kommuner medför år av fördröjning tills proejktresultatet verkligen finns ute tillkommande finansiering uteblir för nästa fas 5.2 Intresentanalys 5.2.1 Sambruk Organisationen ställs i viss mån för ett nytt förhållningssätt hel öppenhet i produktion och utveckling. 5.2.2 Konsulter Samtliga konsulter har erfarenhet av arbete med offentlig sektor, skola, har tillsammans ett brett kontaktnät och en förhållandevis stor samsyn. 5.2.3 Skolor/kommuner Utvecklingen i olika delar av Sverige, samt i olika skolor är väldigt spretande. En övergripnade analys som gjortts av Sambruk tidigare visar att de flesta anser att nuvarande inlåsningseffekter inte är gynnsamma. Men vad det innebär i praktiken är svårt att veta. För projektets framgång är det tillräckligt att ett antal skolor (5-6) medverkar och ger uttryck för sin vilja att medverka framåt.
20(26) 5.2.4 SKL Också inom SKL pågår olika former av projekt för att stimulera skolans utveckling. Det är lämpligt att bjuda in nyckelpersonerna till samråd så att projektet och SKL kan dra nytta av varandra. Det finns från SKL en i grunden positiv hållning till ivis. 5.2.5 Andra leverantörer Under projektets gång är det lämpligt at bjuda in andra leverantörer och utvecklare, för att få deras åsikter och få upp ett intresse för arbetet.
21(26) 6 Tidsplan och aktiviteter 6.1 Milstolpeplan 2015 Datum per den sista varje månad Jan Jan Feb Mars April Maj Juli Okt Nov Dec Jan Teknisk specifikation av plattformens principer Webbplats med basinformation Säkerhetsprinciper för API Community uppsatt och igång Plattform del 1 (DB, grundarkitektur) Busstjänst webb del Definierade skolor som vill testa busstjänsten Busstjänst komplett färdig att implementeras i skola/kommun Definition av TJÄNST 2 (Modul 2) Busstjänst implementerad Tjänst 2 klar i webbversion Tjänst 2 klar i ev mobilversion Tjänst 2 implementerad Driftsättning i fler skolor. 6.2 Aktivitetsplan Lista av aktiviteter som är tids- och resursuppskattade. 6.3 Tidsplan En aktivitetsplan i form av ett schema, finns i bilaga 1.
22(26) 7 Organisation och bemanning 7.1 Styrgrupp Styrgruppen består av representanter för Sambruk, imcode Partner AB samt myndigheter som ingår i projektet. 7.2 Referensgrupp Referenspersoner som tas in beroende av behov. Några fasta referensepersoner kommer att följa projektet under hela tiden. Övriga ref-personer tas in efter behov och vilja till medverkan. 7.3 Projektgrupp Den grupp som i praktiken utför projektet på innehållsnivå. 7.4 Roller, ansvar och befogenheter Organisationsstruktur som anger projektroller, med tillhörande befogenheter och ansvar: 7.4.1 Projektledare Leder projektet och agerar genom mandat från styrgruppen. Fattar egna beslut avseende teknisk utveckling. 7.4.2 Projektkoordinatör Kodinerar samverkan mellan Sambruk och teknikleverantör, svarar för möteslogistik och kontakter med / anskaffning av aktörer inom oddentlig sektor. 7.4.3 Teknisk projektledare Svarar för teknisk koordinering av utvecklingsteam, bemanning och teknikval. 7.4.4 Löpande organisatorisk beslut Löpande organisatoriska beslut fattas av projektledare och projektkkordinatör tillsammans 7.4.5 Löpande tekniska beslut Avgörande beslut fattas av teknikleverantötren imcode 7.4.6 Styrgruppsmedlem En medlem i styrgruppen fattar tillsammans med andra medlemmar principbeslut om projektets utveckling. Om styrgruppen inte kan enas flyttas beslutsbefogenheten till en representant för Sambruk och en representant för imcode Partner AB tillsammans. 7.4.7 Referensgruppsmedlem Påverkar projektet genom egen kunskap i relevant ämnesområde. Inga formella beslutsbefigenheter.
23(26) 8 Budget - finansieringsplan 8.1 Sambruk Finansiering sker genom VINNOVA. Eget bidrag sker internt från Sambruk, inklusive inräknad skolpersonal. 8.2 imcode Finansiering sker genom VINNOVA. Eget bidrag sker internt från imcode.
24(26) 9 Kommunikation och kvalitetssäkring 9.1 Rapporter och dokumentation VINNOVA kräver kvartalsivsa rapporter om projektets utveckling. Dessa redovisas för styrguppen. Därutöver protokollförs all diskussion i styrgruppen. Inför varje möte sker en skriftlig sammanfattning av de viktigaste händelserna och aktiviteterna i projektet. Teknisk dokumentation skapas utifrån behov. All dokumentation finns tillgänglig på projektets webbplats. 9.2 Ändringshantering 9.2.1 Ändringslogg I formella styrdokument skall bifogas en ändringslogg där ändrad punkt, sammanfattning av ändringen samt person som ansvarar, skrivs in. T ex: Punkt Titel Sammanfattning Ansvarig 5.2.2 Konsulter Detaljerad redovisning införd LR 8 Budget Tilläggsbudget från SKL HL 9.2.2 Protokoll Alla formella möten skall protokollföras. Till protokollet skall bifogas en attgöra lista med principen: Att göra Ansvarig Klar datum Ny punkt att göra HL 2015-02-15 Punkt utförd sedan föregående protokoll LR 2015-01-15 Punkt utförd för 2 protokoll sedan [borttaget] HL 2014-12-15
25(26) 10 Riskanalys och riskhanteringsplan Riskidentifiering, riskvärdering och plan för riskåtgärdsplanering. En lämplig metod för att kvantifiera och kvalificera risker är Miniriskmetoden (se dokument Riskanalys ). 10.1 Samverkan Samverkan med skolan kan bli tidskrävande (Sannolikhet: 3 av 5) Konsekvens: systemet blir mindre förankrat och behöver använda reservtid för utvecklingen. Lösning: projektet samverkar med vana kända personer och konsulter (genom föreningen Sambruk) 10.2 Avhopp från skolor Projektet får avhopp från testskolor (Sannolikhet: 2 av 5) Konsekvens: Tillräcklig skarp testning kan inte genomföras. Leveransen försenas. Lösning: tät samverkan med Sambruk och de inblandade skolorna. 10.3 Långa avtalstider Befintliga långa låsta avtalstider med skolleverantörerna (Sannolikhet: 5 av 5) Konsekvens: Övergången till en öppnare modell försvåras. Lösning: Tålmodig marknadsbearbetning i små steg, en modul i taget. Skapa och driftsätta moduler med högre användarnytta än de befintliga leverantörerna. Skapa ny verklig nytta för skolorna/kommunerna.
26(26) 11 Övrigt 11.1 Bilaga 1 Aktivitetsplan I bilaga finns en detaljerad aktivitetsplan 11.2 Bilaga 2 VINNOVA ansökan I bilaga finns en förkortad VINNOVA ansökan.