Underlätta lärares administration av elevuppgifter för externa läromedel en SCIM-klient

Transkript

1 SCIM-klient - specifikationsskiss Datum Juni 2018 Version 1.0 Sida 1(6) Författare Sven-Håkan Olsson Underlätta lärares administration av elevuppgifter för externa läromedel en SCIM-klient Detta dokument innehåller en kortfattad skiss till specifikation för att kunna underlätta lärares administration av elevuppgifter för externa läromedel en s.k. SCIM-klient. Författaren har dock endast mycket översiktligt satt sig in i området, så omfattande brasklappar får utfärdas. Två helt olika etappmål skissas nedan, ett som ligger nära den existerande piloten, och ett som är betydligt mer ambitiöst. Dessutom beskrivs ett mellanting, dock utan tidsuppskattning. 1. Etappmål där tekniker är huvudanvändare för elevadministrationen Den pilotapplikation som finns idag i Ängelholm är helt gjord för att användas av tekniker. Exempelvis måste användaren förstå tekniska LDAP-frågor och måste själv leta reda upp och förstå de elevkategoriseringar som finns inom just den aktuella skolenheten. Det krävs också att käll-applikationer såsom Procapita/IST i förekommande fall föder LDAP-katalogen med elevdata, inkluderande tillräckliga informationsfält. Några användningsfall (eller del-användningsfall) med tillhörande härledda krav (bokstavsnivån nedan): 1.1. Initiala förbereder för att vissa elever ska få tillgång till något externt läromedel a) Lärare, central skoladministratör och tekniker samråder om vad som ska beställas och för vem. Troligen är det endast enkla läromedel och sådant som används under en längre tidsperiod som blir praktiskt att hantera i denna etapp. Liknar dagens pilotapplikation. b) Teknikern översätter detta till LDAP-frågor som konfigureras in i applikationen och provkörs. Resultatet stäms av med lärare/skoladministratör. Liknar dagens pilotanvändning. Postadress Föreningen Sambruk Högbovägen 45 SE Sandviken Hemsida E-post info@sambruk.se Organisationsnr

2 2(6) 1.2. Överför till läromedelsleverantörer a) Teknikern utför körning där SCIM-datat enligt ovan överförs. LDAP-data ska transformeras om till SS1200-standarden. Den gamla piloten är inte anpassad till denna standard utan till enklare SCIM-data. Det är heller inte helt klart vilka konventioner som ska användas utöver SS12000-standarden, t ex är kodning av lärare vs elevgrupp inte självklar. Överenskommelse mellan läromedelsleverantörerna måste förutsättas ha etablerats utanför projektet vad gäller dessa konventioner (annars behöver tidsinsatsen nedan ökas). Arbetsinsats för utveckling/modultest/integrationstest: Uppskattning 90 tim SCIM-klienten gör bakgrundskörningar a) En viktig aspekt är att à jour-hålla informationen hos läromedelsleverantören så att inte inaktuell info finns där, eller kostnader rullar på av slentrian. i. Om en elev slutar eller en elevgrupp tas bort, slås ihop, eller vid läsårsbyte etc så ska gruppens medlemmar uppdateras hos läromedelsleverantören. Gruppidentitet och ändringar i medlemskap måste alltså kunna generera uppdateringshändelser. Dagens s.k. delta-hantering kan troligen återanvändas. Arbetsinsats för utveckling/modultest/integrationstest: Uppskattning 30 tim. Eventuellt byter man istället till robustare lösning med läsning hos leverantör och jämförelse med LDAP för att skapa deltat, skulle dock ta längre tid. ii. iii. (Annat elev-metadata såsom mobilnr etc replikeras inte i denna etapp.) (Specifika tidsgränser för att använda ett visst läromedel en viss period hanteras inte i denna etapp.) 1.4. Tekniska detaljer a) Om man vill utgå från dagens pilotapplikation behöver man se till att den är portabel till Windows eftersom många kommuner har sådan servermiljö. Det kan röra sig om detaljer som små/stora bokstäver samt specialtecken i filnamn, längd på path/filnamn, placering av filer i filsystemet, Scheduler istället för cron mm, mm. Det kan tänkas att programbibliotek som finns i dagens Linux-applikation inte finns för Windows utan måste ersättas. Certifikathanteringen är troligen olika. Arbetsinsats för utveckling/modultest/integrationstest: Uppskattning 60 tim. b) Det förutsätts att gamla pilotens autentiseringsteknik i maskin-till-maskingränssnittet till leverantörerna behålls Övrigt arbete - uppskattad tidsåtgång a) Insats för behovsdialog, samordning etc med utsedda tekniker/skoladminstratörer, Skolfederationen, läromedelsleverantörerna mfl intressenter: Uppskattning 60 tim. b) Insats för övergripande integrationstest/inter-op-test i samarbete med läromedelsleverantörerna: Uppskattning 20 tim. per läromedelsleverantör.

3 3(6) 1.6. Eleven loggar in hos läromedelsleverantören 1. Eleven ska i många fall logga in hos läromedelsleverantören för att få tillgång till själva läromedlet. i. Skolfederation tänks kunna användas för att redan gjord autentisering ska kunna användas. ii. (Denna hantering exkluderas ur föreliggande projektvariant.) 1.7. Sammanställning uppskattad arbetsinsats Ovanstående tidsuppskattningar summeras till: (vid en läromedelsleverantör). 260 tim Kommentarer Det ska dock betonas att med bra "flyt" kan det ta betydligt mindre tid. Ökade besvärligheter i samarbetet, "scope creep", ovana vid behövda teknikmiljöer, teknikstrul etc kan ge högre tidsåtgång tidsuppskattningen ovan är dock relativt pessimistisk.

4 4(6) 2. Etappmål där läraren är huvudanvändare för elevadministrationen Detta skulle kunna vara ett etappmål längre fram när man har vunnit erfarenheter från etappen som föreslås ovan, och erfarenheter från andra parter under mellantiden. Några användningsfall (eller del-användningsfall) med tillhörande härledda krav (bokstavsnivån nedan): 2.1. En lärare förbereder för att vissa elever ska få tillgång till något externt läromedel 1. Läraren utgår från de elevkategoriseringar som finns inom aktuell skolenhet. a. SCIM-klienten måste därför kunna visa upp elevkategoriseringarna och ingående elever hos just denna skolenhet. b. Lärare utgör härvid sällananvändare samt icke-tekniker vilket innebär att detta användargränssnitt måste göras mycket användarvändligt. c. Elevkategoriseringarna måste läsas ur källregister som just denna skolenhet har det kan röra sig om LDAP (AD, edirectory osv) med varierande strukturer, Procapita, IST osv. Därmed måste SCIM-klienten kunna konfigureras för helt olika elevkategoriseringssätt och åtkomstteknik, alternativt att man skapar "plug-ins" för de vanligaste källregistren. Även om alla skulle läsa ur LDAP är olika kommuner/skolor troligen helt olika däri. Konfigurering riskerar bli komplex om den ska vara flexibel nog, plugin-tanken är förmodligen bättre. 2. Läraren får bara ha accessrätt till "sina" elevkategorier. Det behöver därför finnas ett rättighetsregister som kopplar elevkategorier enligt den struktur som resp skolenhet har, till läraren. 3. Läraren väljer ur elevkategoriseringarna ut den grupp elever som denna gång ska få tillgång till läromedlet En lärare förbereder vilket externt läromedel det handlar om 1. Läraren behöver kunna välja ut vilket läromedel från viss leverantör som det gäller. a. I det enklaste fallet har läraren via något annat system eller läromedelskatalog tillgång till artikelnummer e dyl som manuellt får matas in. b. I ett mer användarvänligt scenario finns läromedelskatalogen tillgänglig i SCIM-klienten så att läraren lätt kan välja rätt. Troligen i en senare etapp? c. De olika integrerade läromedelsleverantörerna finns valbara i en lista. De måste alltså vara inkonfigurerade i SCIM-klienten. Konfigurationen inbegriper även anrops-url:ar, credentials mm. Då nya läromedelsleverantörer tillkommer eller gamla faller ifrån behöver konfigurationen uppdateras från något förvaltningsansvarigt håll. 2. Läraren ska också välja hur länge läromedlet ska köpas a. SCIM-klienten lagrar tidsgränsen. Se ang bakgrundskörningar nedan.

5 5(6) 2.3. En lärare begär attest för att få köpa läromedlet 1. För att inte få galopperande kostnader behöver läraren begära attest av en ansvarig om beställningsbeloppet är över en viss konfigurerbar gräns. a. Det behöver gå att definiera attestpersoner per skolenhet eller sub-enhet, eller per lärargrupp etc. b. Attestbegäran skickas t ex i epost som innehåller en länk in i applikationen. 2. Efter autenticering attesterar personen beställningen (eller inte). a. Attestsvaret skickas i epost till läraren 3. Efter positivt svar kan läraren gå vidare En lärare utför själva köpet av läromedlet Läraren lägger, efter ev attest, beställningen till läromedelsleverantören. Ev kan detta steg utföras automatiskt direkt efter positivt attest-svar (eller då attest inte behövs). a. SCIM-klienten kommunicerar med läromedelsleverantören och lägger beställningen. b. SCIM-klienten ska i maskin-till-maskin-gränssnittet till leverantören autentiseras. Detta kan ske på många sätt, i tidiga etapper kan man tänka sig credentials såsom enkla klient-cert eller BasicAuth/https, i senare etapper mer eleganta federeringslösningar SCIM-klienten gör bakgrundskörningar En viktig aspekt är att à jour-hålla informationen hos läromedelsleverantören så att inte inaktuell info finns där, eller kostnader rullar på av slentrian. a. Förutsatt att attest och beställning gått bra, används tidsgränsen som nämns ovan för att kunna göra periodiska bakgrundskörningar för att längre fram skicka information till läromedelsleverantören att ta bort elevernas rätt till läromedlet. b. Om en elev slutar eller en elevgrupp tas bort, slås ihop, eller vid läsårsbyte etc så ska gruppens medlemmar uppdateras hos läromedelsleverantören. Gruppidentitet och ändringar i medlemsskap måste alltså kunna generera uppdateringshändelser. c. Om annat elev-metadata överförs såsom elevers mobilnr etc ska även uppdateringshändelser vad gäller sådant data replikeras över till läromedelsleverantören Eleven loggar in hos läromedelsleverantören Eleven ska i många fall logga in hos läromedelsleverantören för att få tillgång till själva läromedlet. d. Skolfederation tänks kunna användas för att redan gjord autentisering ska kunna användas. e. (Denna hantering exkluderas ur föreliggande projekt.) Denna ansats, med högre ambitionsnivå, är alltför svår att göra tidsuppskattningar. Rekommenderas att arbeta agilt och i små etapper för att uppnå bästa resultat.

6 6(6) 3. Etappmål, där central skoladministratör är huvudanvändare för elevadministration Ett mellansteg mellan alternativ 1, där tekniker är huvudanvändare och 2, att lärare är huvudanvändare: Vidareutveckla applikationen, så att en central skoladministratör (som inte är tekniker) kan använda systemet. Då behövs t ex inte accessrättshanteringen enl ovan, troligen inte attest, samt att användargränssnittet inte behöver vara lika användarvänligt, utan kan exponera en viss begränsad mängd teknikaliteter.