Öppna etjänster för Skolan

Transkript

1 - 1 (16) - Utskrift: 2013/09/12 Öppna etjänster för Skolan Sambruk (ver 6.0) Utarbetad av: Hillar Loor, senior partner

2 - 2 (16) - Utskrift: 2013/09/12 Innehållsförteckning 1 Öppna etjänster för skolan Vision Projektmål Filosofi Definition av plattformen Grundplatta Tätt kopplade funktioner Kommunikation till systemet Kommunikation från systemet Dubbelriktad Kommunikation Användarklienter Mobila webbgränssnitt Mobila Appar Webbgränssnitt för dator Funktionshindrade Licens- och modellproblematik en forskningsansats Bakgrund Förvaltningsperspektivet FoU-resursens ansvarsområde Projektet Iteration Iteration Iteration Kostnad Definitionsarbeten Implementering Forskning och utveckling Kontakt... 16

3 - 3 (16) - Utskrift: 2013/09/12 1 Öppna etjänster för skolan Detta dokument är en projektbeskrivning av ett projekt avsett att ta Sambruks och SKLs tidigare skolprojekt ett steg närmare praktiskt förverkligande. 1.1 Vision Vår långsiktiga vision är att skapa en komplett öppen plattform för skolans verksamheter, omfattande alla skolformer från Barnomsorg till Vuxenundervisning och även omfattande anpassningar till funktionshindrade. Plattformen och plattformens API:er skall vara öppna för alla leverantörer som önskar skriva programvara mot systemet. Plattformen skall levereras som öppen källkod. 1.2 Projektmål Målet för delprojektet som beskrivs i detta dokument är: a. att teknisk definiera en första del av plattformen b. att tillverka en basfunktionalitet serverside c. att tillverka en anropande mobil tjänst som arbetar mot basfunktionaliteten i punkt b. d. analys av ansatsen att stegvis öppna en befintlig plattform till att vara baserad på öppen källkod, så att både Sambruksmodellen och leverantörens affärsmodell kan anpassas till en för bägge parter förmånlig lösning. Målet blir därmed att skapa en fungerande prototyp som också är ett första steg i utvecklingen av en fullständig plattform för öppna e-tjänster, inkluderande en affärsmodell. 1.3 Filosofi Arbetet bygger på övertygelsen att en öppen plattform, byggd på öppen källkod och med öppna API:er (tekniska gränssnitt), ger kraftiga fördelar jämfört med de befintliga proprietära lösningarna som i huvudsak används idag. Vi är övertygade om att: användning av öppna APIer ger en möjlighet för flera leverantörer att ansluta egenutvecklade funktioner, t ex applikationer för mobil användning användning av öppen källkod påskyndar utvecklingshastigheten generellt genom att resurser flyttas från fokus på licensavgifter till fokus på vidaerutveckling

4 - 4 (16) - Utskrift: 2013/09/12 produkter med öppen källkod inte enkelt kan göras proprietära eftersom det ju existerar öppen kod som redan distribuerats öppet. Därigenom kan fientliga uppköp från proprietära leverantörer förhindras. Sådana uppköp har tidigare minskat utvecklingshastigheten i Sverige. Vi motverkar monopol eller oligopol genom ett öppet förhållningssätt

5 - 5 (16) - Utskrift: 2013/09/12 2 Definition av plattformen Funktionerna som definieras i detta kapitel har definierats som en komplett grundplatta med kringkommunikation och -system, i material vi fått oss tillsänt av Peter Dacke, Botkyrka kommun. Tidigare projekt har genomfört en noggrann utredning som vi lägger i botten för detta implementeringsprojekt. 2.1 Grundplatta Denna punkt avser ett antal funktioner som alla ger grundläggande förutsättningar för att hantera verksamheten inom barnomsorg och skola. Grundplattan finns definierade i bilden nedan, samt i punkterna , en uppräkningar av data som måste sparas och hanteras av det vi valt att kalla grundplattan Barn och elever BO/GR/GY/Musk/VUX/SFI/SÄ Personuppgifter (pnr, postadr, folk.bokf.adr, ursprungsland) Kontaktuppgifter (tel hem, tel arb, mobil, mail (tilldelad o privat) Familjebild (VH, syskon) Enheter Klass eller Avdelning (FSK, FTH, DBV)/undervisningsgrupp Årskurs GR/GY/SÄ Ämne/kurs (GR/GY/VUX/MUSK/SÄ)

6 - 6 (16) - Utskrift: 2013/09/12 Lärare (Kan ha flera roller eller vara flera st) Betyg Skolform Studieväg/Programplan/Studieplan Uppflyttning av årskrus/avdelningar (funktion) Antal veckotimmar för BO Placering Taxekategori BO Deb avvikelse Anmärkningsflik/Noteringsfält för GR/GY(BO/Musk/VUX/SFI/SÄ Egna uppgifter / Tabell Räkningsmottagare Instrument MUSK Personens modersmål Koppling till Metakatalog Personal Personuppgifter (pnr, postadr, folk.bokf.adr) Kontaktuppgifter (tel hem, tel arb, mobil, mail (tilldelad o privat), SIGN) Enheter de är anställda på (kan vara olika skolformer) SCB kod Lärares behörighet i ämnen Tjänstefördelning Undervisningsgrupp Koppling till Metakatalog Befolkningsuppgifter från skatteverket Folkbokförda i och utanför kommunen som vi har en relation med Personer med samordningsnummer Uppdatering från skatteverket (automatisk eller manuell hämtning) Gatuadress/Lgh-nummer Verktyg för personmatchning Sekretessbelagda personuppgifter Enheter Enhets ID Enhetsnamn Kontaktuppgifter (vxl telnr, e-post, gatuadress, postadress, koordinat) Undervisningsgrupp Koder (kommunkod, SCBkod, skilidkod, CSNkod) Driftform/Huvudman samt skolform Kontosträngar för utbetalning eller debitering

7 - 7 (16) - Utskrift: 2013/09/12 Organisationsnummer, PG/BG, fakturaadress Termin/period/Läsår Skolpliktsbevakningsområde/OmrådesID 2.2 Tätt kopplade funktioner Till Grundplattan kopplas ett antal näraliggande funktioner Export/Import filer Nyckelkoder från SCB import Betygsfiler GR till GYIntag/SCB (filformat.txt) Import/export av filer Gyantagningen Resultatfil för Ämnesprov (filformat.txt) Fil med personalstatistik till SCB (filformat.txt) Betygsfiler för GY/VUX till VHS Fil till CSN för GY och VUX elevfrånvaro, studerande Fil med upptagningsområde till kartfunktion Fakturering Skapa underalg för fakturering till alla räkningsmottagare Räkningskorrigering bakåt och framåt Temp-körningar varje månad Kunna kopplas samman med Ekonomisystem Stänga av bakåt i systemet vid rättningar Kunna beräkna fakturor för kommande månad Göra inkomstförfrågningar utifrån valbart underlag i systemet Inkomster för VH Debitering/Fakturering MUSK Resursfödelning Kunna kopplas samman med Economa Kunna göra för-körningar Utbetalning av elevpeng till enheterna 2 steg Massgenererering av e-postutskick för rapporter i resursfördelningen Koppling elev bankutbetlaning för GY Inackorderingstillägg för GY Rese/matersättning

8 - 8 (16) - Utskrift: 2013/09/ Rapporter (måste finnas inbygd rapportgenerator) ex Betyg (terminsbetyg, slutbetyg) Betygskataloger (Lpo94 samt per ämne) Studieplan Klass- Grupplista Skolpliktsbevakning Adressetiketter m fl Handläggare för BO vid ex 2.3 Kommunikation till systemet Systemet måste importera och hantera data från andra system. I punkterna redovisas de primära importfunktionerna, där en återexport inte är nödvändig Schema program Modul Praktik (GR/GY) Modul Skuldhantering Modul Vårdnadsbidrag 2.4 Kommunikation från systemet Systemet måste även kunna exportera data, i första hand som sammanställningar. Dessa redovisas nedan i punkterna V-Klass Inlogg föräldrar Skolportal Elev- och klasslistor Modul Statistik Statistik från samtliga skolformer och kopplade etjänster 2.5 Dubbelriktad Kommunikation Systemet måste även kunna hantera en mer komplex import/export genom integration med andra näraliggande system och etäjnster. Dessa finns nedan i punkterna IUO/Omdömen GY/GR Inlogg föräldrar

9 - 9 (16) - Utskrift: 2013/09/ E-tjänst BO ej barnkön Inlogg föräldrar E-tjänst Betyg (GY/GR/VUX + ÄP) Registrering av Frånvaro/Närvaro Inlogg föräldrar E-tjänst GY val Inlogg användare E-tjänst GY Studieval Inlogg användare E-tjänst ansökan Vux val + manuell inmatning VUX Inlogg användare E-tjänst Vux studieplan Inlogg användare E-tjänst Skolval Inlogg föräldrar E-tjänst Musik & Kultur Inlogg föräldrar Behörighetsprogram Styra åtkomst till olika delar av verksamhetssystemet

10 - 10 (16) - Utskrift: 2013/09/12 3 Användarklienter Till plattformen som beskrivs i punkt 2, kopplas olika former av klienter som använder data från plattformen. Genom uppdelningen plattform / klient kan användarklienter specialanpassas till särskilda gruppers behov. Det blir t ex möjligt att ha helt olika klienter för elever, lärare, administrativ personal etc. Det blir också möjligt att låta valfri extern part skriva klienter som anropar plattformen och hämtar data därifrån. I sin enklaste form är klienterna HTML-sidor (webbsidor). Men klienter kan också vara programvara för datorer, eller appar för mobilanvändning. I detta projekt bygger vi enbart en enkel klient för att vara proof of concept. De klienter vi i ett större perspektiv kan se är lämpliga att bygga är: 3.1 Mobila webbgränssnitt Det behövs ett antal mobila gränssnitt för användning i klassrummet, på lärarnas arbetsplatser, av elever och av föräldrar. Dessa gränssnitt kan byggas i HTML5 och användas i de fleta mobila enheter, som plattor eller mobiltelefoner. 3.2 Mobila Appar En mer avancerad möjlighet är att tillverka appar utifrån målgruppens behov. Appar har fördelen att man hårt kan styra, och därmed förenkla användandet. 3.3 Webbgränssnitt för dator Genom arbetet med mobila gränssnitt kan man troligen reducera behovet av webbgränssnitt för elever och föräldrars fasta datorer. Däremot kan en komplexare situation för administratörer kräva webbgränssnitt med access till såväl mer data som fler funktioner. 3.4 Funktionshindrade Speciellt fokus bör läggas på att ta fram mobila gränssnitt för funktionshindrade. Detta är ett eftersatt område som begränsar dessa gruppers möjligheter att ta del av samma informationsflöde som icke fuktionshindrade. Genom att hela systemet byggs baserat på plattform med API:er som man kan koppla in olika former av klienter till, kan man i hög grad bygga anpassade gränssnitt för funktionshindrade, som inte samtidigt måste ta hänsyn till andra gruppers behov.

11 - 11 (16) - Utskrift: 2013/09/12 4 Licens- och modellproblematik en forskningsansats 4.1 Bakgrund Vårt antagande ovan utgår ifrån att en befintlig plattform kan skrivas om och anpassas till skolans verksamhet. Den ska inte behöva utvecklas från grunden. Det finns ett antal sådana plattformar på marknaden, varav vi har funnit en där leverantören är beredd att under en flerstegsperiod omvandla plattformen till öppen källkod. Offentlig sektor (Sambruks medlemmar) är idag starkt beroende av proprietära lösningar, som i praktiken ger vissa leverantörer oligopol byggd på licensmässiga grunder. Samtidigt finns det inte öppna verksamhetssystem att tillgå i någon större omfattning. En omvandling av en befintlig sluten plattforms affärsmodell till en öppen modell kan komma att bli en av de viktigare kunskaperna efter detta projekt. Sambruks projektmodell tillämpar i egenutveckling en semi-öppen modell med sina medlemmar. Detta är attraktivt för en leverantör som inte helt direkt kan finna öppna licensmodeller som fungerar affärsmässigt. Genom att först gå in i Sambruks "semi-öppna" modell och sedan tillsammans med Sambruk öppna programvaran helt, är en metod med lägre risk, som kan komma att bli en god omvandlingsmodell för fler, och därmed gynna offentlig sektor. Projektet omfattar därför en FoU-resurs på universitetsnivå, med kompetens och erfarenhet inom området öppen källkod. 4.2 Förvaltningsperspektivet Projektet kommer att komma in i en förvaltningsfas när väl hela programvaran är utvecklad, dvs en bra stund efter att detta projekt avslutats. Det finns ändå skäl att reflektera över SGM-modellen och användning av en semi-öppen licens inom SGM-ramverket alternativt en helt öppen licens. Plattformsleverantörens ambition är att långsiktigt öppna sin befintliga plattform till öppen källkod. Dock finns det ett antal frågetecken på vägen som måste lösas i någon form av transitionsprocess. SGM-ramverket öppnar just möjligheten att närma sig en öppen kod, utan att behöva ta hela risken på den internationella marknaden. Plattformsleverantören har helt accepterat modellen med att Sambruk initialt får rätt att använda, vidareutveckla och vidaredistribuera plattformskoden inom kommunernas skolverksamhet. Det innebär att det internt för Sambruks medlemmar inte finns någon inlåsningseffekt. Sambruk har däremot initialt inte rätt att distribuera koden eller en förändrad kod utanför den angivna verksamheten.

12 - 12 (16) - Utskrift: 2013/09/12 I ett längre perspektiv önskar plattformsleverantören öppna koden dvs leverera den som öppen källkod. Då uppstår frågan om Sambruk önskar använda den utvecklade koden under en öppen licens, eller om plattformen (utan skolmodifieringar) i sig ska kunna dubbellicensieras, dvs både under en proprietär och en helt öppen kod. Under alla omständigheter kommer Sambruk att ha kontroll över den färdiga skolplattformen, men kan i ett längre perspektiv komma att välja att i sin tur licensiera skolplattformen helt öppet. Med hjälp av FoU-resursen kan dessa frågeställningar belysas och möjligen skapa en modell för transition från en stängd till en öppnare kod inom offentlig verksamhet. 4.3 FoU-resursens ansvarsområde Analys av Specifikations- och realiseringsarbetet Arbetet bedöms utifrån de eventuella fördelar och nackdelar som uppnås genom den valda ansatsen, t ex inom områdena immateriella rättigheter, licensmodeller, affärsmodeller samt omvandlingsmodellen för proprietär licens till semi-öppen och till slut öppen licens. Analysen bör i första hand omfatta ekonomiska faktorer och utvecklingshastighet för plattformsleverantören och för Sambruk/kommunen FoU-insatsen bistår med bedömning av hur projektgruppens (experter, projektansvarig, plattformsleverantör, Sambruk) samarbete och effektivitet/produktivitet påverkas av valet av befintlig plattformsprodukt.

13 - 13 (16) - Utskrift: 2013/09/12 5 Projektet Detta projekt delas upp i ett antal delmål / iterationer. Iterationerna nedan följs av FoU-resursen som definierats i punkt Iteration 1 Projektet definierar teoretiskt kraven för Grundplattan enligt 2.1. Vi undersöker om den tyska plattformen ADAICA kan användas som bas för att implementera grundfunktionaliteten. Arbetet sker genom att vi definierar nödvändig funktionalitet och beräknar implementeringstiden i ADAICA. 5.2 Iteration 2 Vi väljer ut en grundfunktion som kan implementeras i ADAICA. Preliminärt ser vi nedanstående: En delmängd av punkt Barn och elever BO/GR/GY/Musk/VUX/SFI/SÄ Personuppgifter (pnr, postadr, folk.bokf.adr, ursprungsland) Kontaktuppgifter (tel hem, tel arb, mobil, mail (tilldelad o privat) Familjebild (VH, syskon) Enheter Klass eller Avdelning (FSK, FTH, DBV)/undervisningsgrupp Årskurs GR/GY/SÄ Ämne/kurs (GR/GY/VUX/MUSK/SÄ) Lärare (Kan ha flera roller eller vara flera st) Skolform Studieväg/Programplan/Studieplan Uppflyttning av årskrus/avdelningar (funktion) Placering Anmärkningsflik/Noteringsfält för GR/GY(BO/Musk/VUX/SFI/SÄ Egna uppgifter / Tabell Personens modersmål Delmängder som inte implementeras i detta projekt: Betyg Antal veckotimmar för BO Placering Taxekategori BO Deb avvikelse Räkningsmottagare Instrument MUSK Personens modersmål Koppling till Metakatalog

14 - 14 (16) - Utskrift: 2013/09/ Iteration 3 Tillverkning av en mobil tjänst som hämtar data ur systemet, via öppna APIer. Initialt gäller: egen persondata (som ska kunna ändras) klasslistor grupplistor

15 - 15 (16) - Utskrift: 2013/09/12 6 Kostnad Kostnaden för det första delprojektet är: 6.1 Definitionsarbeten Definition enligt 5.1 projektledning : Definition enligt 5.1 ADAICA :- 6.2 Implementering Basfunktionalitet platta enligt : Basfunktionalitet webbtjänst enligt : Projektledning av implementering :- 6.3 Forskning och utveckling Resurs enligt punkt :-

16 - 16 (16) - Utskrift: 2013/09/12 7 Kontakt Hillar Loor, senior partner hillar@imcode.com imcode Partner AB Skeppsbron VISBY info@imcode.com Tel: Fax: