Förstudie avveckling av EPi-Server för EBH-stödet

Transkript

1 Förstudie avveckling av EPi-Server för EBH-stödet

2 Alternativ 0 Behåll befintlig funktinalitet ch design ch behåll även EPi-Server Fördelar: Man slipper den engångskstnad sm blir med alternativ 1 respektive alternativ 2 Nackdelar: Kden kmmer även frtsatt att vara föråldrad, vilket innebär stra begränsningar i vilken nyutveckling sm är möjlig att göra i systemet. Begränsningarna i den nyutveckling sm är möjlig innebär bland annat att utrymmet att göra anpassningar sm underlättar för kmmunernas behv är avsevärt mindre. Det kmmer även frtsatt att vara lika tidskrävande sm nu för utvecklarna att rätta buggar ch nyutveckla, vilket innebär frtsatt höga utvecklingskstnader per utvecklingsuppgift Det finns inga autmattester i EBH-stödet idag ch är inte heller möjligt att utveckla i befintligt system. Autmattester ger säkrare test vid ny utveckling ch minskar den tid sm verksamhetens bjektspecialister måste avsätta för testning. Det kmmer även frtsatt att vara lika tidskrävande sm nu för verksamhetens bjektspecialister att testa ch återtesta ny utveckling Enda systemet med EPi-Server inm länsstyrelsernas driftsmiljö Årliga licenskstnader, sm kmmer att öka för att få bästa kapacitet med EPi-Server IT-enheten har ingen egen kmpetens inm EPi-Server, vilket innebär merkstnad för extern knsult för hantering av EPi-Serverspecifika frågr Ingen långsiktighet i att EBH-stödet byggs på EPi-Server, enligt IT-enhetens bedömning Utvecklingslicensen för EPi-Server tillåter bara att en webbserver på utvecklingsservern använder licensen. Detta betyder att knsulterna får turas m för att lägga upp ny utveckling på servern, vilket utgör ett hinder i utvecklingsarbetet ch är mindre effektivt.

3 Alternativ 1 Behåll befintlig funktinalitet ch design, men ta brt berendet av EPiServer. Fördelar: Licenskstnaderna för EPiServer försvinner Berendet av den EPiServer-specifika kden försvinner Enligt knsultens uppskattning ca 10-20% mindre utvecklingstid vid ändring ch tillägg av befintlig kd OM EBH-stödet INTE ska finnas kvar på längre sikt kan det vara en eknmisk vinst i att behålla befintlig arkitektur ch endast ta brt EPiServer-kpplingarna Nackdelar: En engångskstnad för utvecklingsinsatsen Kden kmmer även frtsatt att vara föråldrad, vilket innebär stra begränsningar i vilken nyutveckling sm är möjlig att göra i systemet. Begränsningarna i den nyutveckling sm är möjlig innebär bland annat att utrymmet att göra anpassningar sm underlättar för kmmunernas behv är avsevärt mindre. Det kmmer även frtsatt att vara tidskrävande för utvecklarna att rätta buggar ch nyutveckla, vilket innebär frtsatt höga utvecklingskstnader per utvecklingsuppgift Det finns inga autmattester i EBH-stödet idag ch är inte heller möjligt att utveckla i befintligt system. Autmattester ger säkrare test vid ny utveckling ch minskar den tid sm verksamhetens bjektspecialister måste avsätta för testning. Det kmmer även frtsatt att vara lika tidskrävande sm nu för verksamhetens bjektspecialister att testa ch återtesta ny utveckling. Möjligheter att förbättra användarvänligheten finns alltid, men är mer begränsade med alternativ 1 jämfört med alternativ 2 Estimat uppskattad tid för utvecklingsinsatsen: timmar Observera dck att detta är endast ett preliminärt estimat. Utan en kmplett detaljerad lösningsspecifikatin kan knsulten inte förbinda sig till en mer exakt uppskattning av antal timmar.

4 Fördelar: Alternativ 2 Utgå från önskad funktinalitet ch skapa ett nytt EBH-stödet 3.0. Berendet av EPiServer tas samtidigt brt. Licenskstnaderna för EPiServer försvinner Berendet av den EPiServer-specifika kden försvinner Systemet blir betydligt enklare ch billigare att vidareutveckla, förvalta ch underhålla Krtare utvecklingstid per utvecklingsuppgift. Enligt knsultens uppskattning ca 40-50% mindre utvecklingstid vid ändring ch tillägg av befintlig kd Krtare startsträcka när nya utvecklare ska sätta sig in i befintlig kdbas Str valfrihet i vilka ändringar ch förbättringar sm kan göras i systemet, vilket även innebär möjligheter att göra anpassningar sm underlättar för kmmunernas behv Stra möjligheter att förbättra användarvänligheten Möjlighet att anpassa till nya behv längre fram, vilket även innefattar möjlighet att anpassa till andra enheter (surfplatta, telefn) Möjlighet att bygga in autmattester. Autmattester ger säkrare test vid ny utveckling ch minskar den tid sm verksamhetens bjektspecialister måste avsätta för testning. Nackdelar: Hög engångskstnad för denna utvecklingsinsats Estimat uppskattad tid för utvecklingsinsatsen: timmar Observera dck att detta är endast ett preliminärt estimat. Utan en kmplett detaljerad lösningsspecifikatin kan knsulten inte förbinda sig till en mer exakt uppskattning av antal timmar.

5 Hur ser framtiden ut för EBH-stödet? Rller för Länsstyrelsen, Naturvårdsverket, kmmunerna? Ska EBH-stödet under ett antal år framöver finnas kvar ch vara det natinella systemet för uppgifter m förrenade mråden? Kmmer EBH-stödet även på ett antal års sikt att vara lika viktigt sm idag? Kan EBH-stödet till ch med få ännu större betydelse de närmaste åren framöver? Eller ska någt annat system ta över denna rll på några års sikt? Från ch med i år hämtar Naturvårdsverket data till nyckeltalsredvisningen direkt från EBH-stödet. Systemet ger ckså underlag till bland annat miljömålsuppföljningar. Nu är det ckså på gång att kmmunerna ges tillgång till EBH-stödet. Det är därför ännu viktigare att systemet är användarvänligt ch fungerar väl. Tre aktörer finns idag med i bilden Länsstyrelsen, Naturvårdsverket ch kmmunerna. Kmmer alla dessa aktörer att ha kvar samma rller sm idag? Finns det någn annan myndighet med annat system sm kan bli aktuell att ta över mtsvarande funktin inm några år?

6 Schematisk bild av hela systemet EBH-stödet

7 Underlaget är framtaget inför EBH-stödets beslutandegrupps möte den 17 mars. Sida 1 av 2 Jämförelse kstnader mellan alternativen 0, 1 ch 2 utifrån Altrans Förstudie avveckling av EPiServer för EBH-stödet *Tabellen visar uppskattade kstnader för alternativen 0, 1 ch 2. En årlig driftskstnad på kr för prduktinsmiljö, utvecklingsmiljö ch testmiljö är knstanta ch kmmer att kvarstå avsett vilket alternativ sm väljs. Eftersm denna summa inte skiljer mellan de lika alternativen har denna kstnad inte tagits med i vanstående tabell. Alternativ 1 Uppskattat utifrån aktuellt underlag kmmer investeringskstnaderna att sparas in på i strleksrdningen 1,5-2 år. Altrans uppskattning av antal timmar för att genmföra alternativ 1 är timmar. Investeringskstnaden för alternativ 1 är kr (beräknat på en timkstnad på 800 kr för Altran, vilket är den aktuella uppgift vi har). I tabellen har den högsta kstnaden använts, mtsvarande 700 timmar. Altrans uppskattning i utvecklingstid sm kan sparas vid alternativ 1 är mellan %. I tabellen har ett medelvärde använts på 15 %. Alternativ 2 Uppskattat utifrån aktuellt underlag kmmer investeringskstnaderna att sparas in på i strleksrdningen 1-1,5 år. Tabellen van visar att med alternativ 2 kmmer det att efter denna investeringsinsats att vara möjligt att antingen få ut i strleksrdningen dubbelt så mycket utveckling för samma kstnad eller att alternativt få samma mängd utveckling till halva kstnaden. Altrans uppskattning av antal timmar för att genmföra alternativ 2 är timmar. Utvecklingskstnaden för alternativ 2 är kr (beräknat på en timkstnad på 800 kr för Altran, vilket är den aktuella uppgift vi har). I tabellen har den högsta kstnaden använts, mtsvarande timmar. Altrans uppskattning i utvecklingstid sm kan sparas vid alternativ 2 är mellan %. I tabellen har ett medelvärde använts på 45 %.

8 Underlaget är framtaget inför EBH-stödets beslutandegrupps möte den 17 mars. Sida 2 av 2 Förvaltningskstnader Förvaltningens kstnader för kravställan ch test är uppskattade utifrån användarrådets samrdnares tidredvisning på dessa kder i Agress. I realiteten tillkmmer det ytterligare tid för övriga testare i användarrådet. Denna tid ersätts dck inte inm förvaltningens budget. Utifrån aktuellt underlag uppskattar användarrådets samrdnare att den tid sm förvaltningen lägger ner på kravställan ch test kmmer att kunna minskas med cirka 25 % m alternativ 2 väljs.

9 Förstudie avveckling av EPiServer för EBHstödet Kmpletterande frågr ch svar

10 Innehåll 1 Alternativen... 3 Alternativ Alternativ Alternativ Förklaring till förstudiens avsnitt Hur långt fram i tiden är det sm är några år? Nyttrna med alternativ Minskade licenskstnader... 3 Minskad kdbas... 3 Lättare applikatin... 4 Ingen främmande fågel... 4 Kmpetenstillgång... 4 Lättare att utveckla Nyttrna med alt Minskade underhålls- ch vidareutvecklingskstnader... 4 Tillgdse dagens behv... 5 Möjlighet att anpassa till andra enheter... 5 Mdern design... 5 Tillgänglighet Vad ingår?... 6 Alternativ Alternativ Tidsvinster för de lika alternativen... 6 Allt berr på utvecklingstakt

11 1 Alternativen De lika alternativ sm finns för EBH-stödet är: Alternativ 0 EBH-stödets kdbas lämnas sm det är. EPiServer-berendet ch all kd i övrigt lämnas sm det är, ch underhåll ch vidareutveckling sker på plattfrmen Micrsft asp.net/webfrms med EPiServer Alternativ 1 Kpplingarna till EPiServer tas brt, vilket lämnar en ren Micrsft asp.net/webfrmsarkitektur Alternativ 2 Existerande backend 1 (Reprting Services, MS SQL databas ch databaslager (EBHWS från förstudien)) behålls, medan lgik ch användargränssnitt byggs m från grunden på Micrsft asp.net MVC-arkitektur 2 Förklaring till förstudiens avsnitt 1.11 Hur långt fram i tiden är det sm är några år? Med några år menade jag här 2-3 år. En mer rättvisande frmulering är kanske Eller kmmer eventuellt någn annan myndighet med annat system att ta över mtsvarande funktin innan någt förändringsbehv av EBH-stödet uppstår? 3 Nyttrna med alternativ 1 Vinsterna med att plcka brt EPiServer-berenden är: Minskade licenskstnader EPiServer är förknippat med en årlig kstnad, ch föremål för versinsuppdateringar när en ny versin föreligger. Utan EPiServer-berende kapas licenskstnad ch eventuella framtida licenskstnadsökningar. Minskad kdbas Varje kdrad i en applikatin är en ptentiell felkälla. En inte föraktlig mängd kd i EBHstödet rör kpplingar mt EPiServer. Ofta används i EBH-stödet EPiServer-specifik funktinalitet sm endast duplicerar redan befintlig funktinalitet i bas-plattfrmen Micrsft asp.net/ Webfrms. Kdbiblitek sm EPiServer har kända in- ch utgångar. Vad sm sker där inne är dck känt. Sker någt väntat eller förutsett inne i ett externt kdbiblitek är det inget sm en utvecklare kan påverka. Ju mindre man använder 1 I ett datrystem brukar man skilja på frntend ch backend. Frntend är användargränssnitt ch kd för att visa infrmatin, Backend är datalager, dataåtkmst ch databearbetning.

12 tredjepartsbiblitek, dest bättre kntrll över prgrammet har man sm utvecklare. Utan EPiServer minskas antal kdrader vilket i sin tur ger mindre mängd kd att underhålla ch ett system sm är lättare att sätta sig in i ch förstå vid underhåll, funktinalitetstillägg ch förändringar. Lättare applikatin Varje kdrad tar ckså tid att utföra när applikatinen körs. Med färre kdrader ch inga anrp av funktiner i EPiServer-bibliteket, kmmer EBH-stödet att blir snabbare ch mer respnsivt. Ingen främmande fågel Inget annat system i Länsstyrelsens IT-miljö använder EPiServer. Ur driftsynpunkt är det bra med en hmgen miljö. Ren Micrsft-kd brde ur den synvinkeln vara att föredra. För EBH-stödets del är ckså EPiServer främmande. EPiServer är främst ett CMS 2 -system, i likhet med SharePint (sm bland annat används sm ramverk för Insidan). EBH-stödet har mycket lite att göra med publicering av texter, nyheter med mera, sm syftet med ett CMSsystem är. Kmpetenstillgång Det finns betydligt fler IT-knsulter sm är bekanta med Micrsft asp.net/ Webfrms än Webfrms/EPiServer Lättare att utveckla Även utvecklingsmiljön kräver en EPiServer-licens. Dck finns endast en licens för utveckling, vilket gör att utvecklarna i teamet måste vänta på varandra vid testkörning ch felsökning, samt stppa EPiServer mellan varje pass. Detta skapar nödiga stpp ch avbrtt i utvecklinsprcessen, ch förlänger utvecklings- ch felksökningstid. 4 Nyttrna med alt. 2 Med alternativ 2 får man samtliga de nyttr sm erhålls med alternativ 1. Utöver nyttrna med alternativ 1 kmmer alternativ 2 att ge: Minskade underhålls- ch vidareutvecklingskstnader Existerande kd är, även med EPiServer-berenden brta, snårig, ch med många väntade kpplingar ch berenden. Samtidigt är stra kdblck ch delar av användargränssnittet duplicerade, där samma kd brde kunna användas. För varje fel sm ska hittas eller förändring sm ska göras i existerande kd, krävs en djup analys av stra delar av kden för att hitta rätt, ch det är svårt att veta m förändringen har väntade effekter på andra ställen i kden, eller m den förändring man gjrt verkligen täcker in alla användningsfall. 42 Cntent Management System (innehållshanteringssystem)

13 Eftersm användargränssnitt ch lgik i Webfrms-arkitekturen är hårt sammanknuten, finns mycket små möjligheter att skapa autmatiska tester av kden Idag finns inga autmatiska tester. Arkitekturen för alternativ 2 ger betydligt större möjligheter att skriva autmatiska tester, vilket resulterar i minskad risk för väntade följdprblem med tidsödande felsökningar sm följd, när förändringar i befintlig kd görs. En ny utvecklare kan göra förändringar utan r för väntade följdfel. Autmatiska tester kan eliminera behvet av manuell genmgång av alla aspekter av applikatinen (så kallad regressinstestning 3 ) vid varje förändring, vilket sparar tid vid acceptanstest inm verksamheten vid Länsstyrelsen. Tillgdse dagens behv Ett prgram sm EBH-stödet mdellerar en verklighet ch prcess så sm den är när prgrammet skapas. Över tid förändras verkligheten ch prcessen kan behöva ändras. Man behåller dck gärna samma prcess sm tidigare (då det är den prcess prgrammet stödjer). I stället för att underlätta prcessen, blir prgrammet ramen för prcessen. Den prcess sm mdellerades för 6-7 år sedan kanske inte är den ptimala idag. En mskrivning av lgik ch användargränssnitt skulle ge tillfälle att m så önskas arbeta m den prcess ch mdell applikatinen ska ge stöd till. Möjlighet att anpassa till andra enheter asp.net/webfrms lanserades långt innan den första smarta telefnen eller surfplattan lanserades. Det är gjrt för presentatin på datrskärm, ch mycket svårt att anpassa till mindre skärmar. Med alt. 2 finns alla möjligheter att skapa användargränssnitt med vad sm kallas för respnsiv design, dvs. att utseende ch sidlayut anpassar sig till vilken typ av enhet (datr, surfplatta, telefn) sm används. Mdern design Vi är idag betydligt mer internet-vana än för 6-7 år sedan, ch har (andra) förväntningar på hur en webbapplikatin ska bete sig. Användarupplevelse är någt man kanske mest talar m i kmmersiella applikatiner, men det är lika viktigt för att få acceptans för ch användning av ett verksamhetsstöd. Har man använt EBH-stödet många år känner man sig hemma i den miljön, men m en mängd nya användare ska ges tillgång till EBH-stödet kan det vara värt att arbeta m utseende ch pedaggik, för att bättre svara upp mt nya användares förväntningar. Tillgänglighet Tillgänglighet handlar m hur lätt applikatinen är att använda, berende av eventuella funktinshinder. Länsstyrelsens webbapplikatiner ska uppfylla tillgänglighetskraven i standarden WCAG 2.0, nivå AA. För att EBH-stödet ska uppfylla dessa krav, krävs 53 När man efter ett funktinstillägg eller felavhjälpning kntrllerar att de gjrda förändringarna inte förrsakat nya fel

14 mskrivning av användargränssnittet, vilket, då kppling mellan webbsida ch bakmliggande kd i befintlig arkitektur är djup, blir ett i sig mycket mfattande prjekt. Med alternativ 2 kan hänsyn till tillgänglighetskrav tas med från start. 5 Vad ingår? Estimaten är Altran-tid. I samtliga fall ingår lösningsspecifikatin ch leverans enligt specifikatin (inkl. ev. buggfixar för att uppnå detta), samt assistans vid prduktinssättning. Alternativ 1 För alternativ ett är kravbilden enkel, ch begränsar sig i strt sett till att EBH-stödet ska se ut ch fungera på samma sätt sm tidigare, utan EPiServer. Här krävs sannlikt mycket lite administrativ tid. Alternativ 2 Alternativ två är kmplexare, ch berr mycket på hur stra förändringar, jämfört med dagens system, sm tas in i prjektet. Andra faktrer sm påverkar är självklart hur mycket tid sm ska läggas på wrkshps, kravmöte, autmattester mm. Jag har i uppskattningen försökt väga in en nrmalnivå på dessa aktiviteter, samt enhetstestning 4 av de viktigaste kddelarna. Enhetstestning tar tid vid det initiala utvecklingsarbetet, men eliminerar mycket tid ch säkerhet vid förvaltning, underhåll ch förändringar. 6 Tidsvinster för de lika alternativen Allt berr på utvecklingstakt Då framtida (för mig kända) behv av underhåll ch nytutveckling är det sm styr eknmin i de lika alternativen, är det möjligt att uppge denna faktr i siffrr. I stället 64 Med enhetstestning testas små kdblck med lika indata för att verifiera att utdata blir krrekt i alla lägen. Terin är att m alla små kdblck testas ch fungerar sm tänkt, kmmer ckså helheten att fungera sm tänkt.

15 försöker jag illustrera det med detta diagram: 7 På vertikal axel har vi kstnad. Alternativ 0 har ingen initial kstnad, alternativ 2 en högre initial kstnad, ch alternativ 1 befinner sig någnstans däremellan. På hrisntell axel har vi hur mycket förändringar sm ska utföras av EBH-stödet i framtiden. Ju mer förändringar, dest snabbare kmmer den initiala kstnaden att ge avkastning i frm av att utvecklings- ch underhållskstnaderna blivit lägre. Man kan ckså kmma till en punkt för alternativ 0 ch 1 där en önskad förändring inte går att åstadkmma alls på den plattfrmen, utan man tvingas att ändå välja alternativ 2 vid en senare tidpunkt. Mycket av de utvecklingsinsatser ch kstnader sm lagts på gamla plattfrmen går då förlrade. Uppskattningsvis blir, vid förändringar av ch tillägg till befintlig kd, vinsten med alternativ %, medan vinsten med alternativ 2 trligen skulle vara runt 40-50%, dvs.

16 tillägg till ch förändringar av EBH-stödets kd skulle ta ca halva tiden jämfört med hur kden ser ut idag. 8

17 Förstudie avveckling av EPiServer för EBHstödet

18 Innehåll 1.1 EBH-stödet idag EBH ch EPiServer idag Avveckling av EPiServer-berenden Behåll befintlig arkitektur Nytt EBH-stöd med ASP.NET MVC EBH-Stödet Rättigheter/Behörighetsnivåer Mdernisering av kd Dagsläge Framtid Tillgänglighet Kmpatibilitet med andra/senare webbläsare, tuchskärmar, små skärmar Internet Explrer 11versin Ggle Chrme versin m Firefx versin Pekskärmar/surfplattr/telefner SharePint-integratin Ärendehantering Kmmunernas åtkmst till EBH-stödet - Kmmunaccessen API Sammanfattning ch rekmmendatin... 14

19 1.1 EBH-stödet idag EPISERVER WEB FORMS ASP.NET EBH REPORTING SERVICES EBH WS SQL DATABAS EBH-stödet utgörs idag av tre kmpnenter: Webbapplikatinen EBH sm är en ASP.NET-lösning med Web Frms-arkitektur. Ovanpå denna finns ett starkt kdmässigt berende till EPiServer, vars funktinalitet dck används i mycket liten utsträckning. I EBH-blcket sker all presentatin ch behandling av data. Data lagras i en Micrsft SQL databas All kmmunikatin mellan webbapplikatin (EBH) ch datalager sker via IISapplikatinen EBH WS. Detta är en Micrsft WCF 1 -applikatin sm tillhandahåller en 31 Windws Cmmunicatin Fundatin

20 uppsättning SOAP 2 -webbtjänster, sm hämtar, uppdaterar ch lagrar data i databas, samt hämtar data från externa system (idag endast Vattenförvaltningens IT-system Vatteninfrmatinssystem Sverige; VISS). Reprting Services används för rapprtuttag för utskrifter ch exprt till vanliga frmat sm PDF, Excel mm. I texten sm följer, avses med EBH blcket/systemdelen EBH i bilden van, medan EBH-stödet syftar på hela systemet; EBH, EBH WS, SQL Databas ch Reprting Services. 1.2 EBH ch EPiServer idag EPiServer används, i den utsträckning det går att bedöma utan en ttal genmlysning av existerande kd, till följande: Åtkmsthantering (auktrisering) Underhåll av texter på startsidan Lagring ch uppdatering av hjälpdkument ch blankettmallar Lagring ch underhåll av länkar till webbgis (lika per länsstyrelse) Dck har samtliga sidr ch funktiner i EBH-stödet referenser ch kpplingar till EPiServer-kd. Ofta har inbyggd ASP.NET/Web Frms-funktinalitet ersatts med mtsvarande EPiServer-funktinalitet. EBH WS, d.v.s. skiktet mellan EBH ch SQL-databas, ch Reprting Services-delarna har inget berende till EPiServer. 1.3 Avveckling av EPiServer-berenden Behåll befintlig arkitektur För att bryta berendet av EPiServer, krävs relativt mfattande mskrivning av befintlig kd. Strategin för detta mment blir att starta ett helt nytt ASP.NET web frms prjekt ch bit för bit hämta in funktinalitet från befintligt system, plcka brt eventuella EPiServerkpplingar tills allt fungerar sm tidigare. 42 Simple Object Access Prtcl

21 Alternativet att utgå från existerande kd ch plcka brt EPiServer-berenden bit för bit känns sm en betydligt riskablare väg att gå, med str risk för ännu mer svåröverskådlig ch svårhanterlig kd, med ökade kstnader för underhåll sm följd. Därtill kmmer att skapa de delar av EPiServer sm utnyttjats i EBH-stödet; auktrisering, texter, dkumentlagring ch länkhantering. Målet för detta är exakt bibehållen funktinalitet ch design, men utan behv av EPiServer, tillhörande licenskstnad ch EPiServer-specifik kd. Även utan EPiServer kmmer dck kdbasen frtsatt att vara snårig ch kmplex med många väntade ch vanliga beteenden ch lösningar. Estimat tidsåtgång: tim Nytt EBH-stöd med ASP.NET MVC EBH-Stödet 3.0 Sm alternativ till van finns möjligheten att, utgående från önskad funktinalitet (snarare än befintlig funktinalitet), skriva m EBH-delen i ASP.NET MVC Förutm de fördelar sm tas upp under avsnittet Mdernisering av kd, ger detta ett system sm är betydligt enklare ch billigare att vidareutveckla, förvalta ch underhålla. De lika delarna sm idag utgör EBH-stödet kan angripas var för sig. Steg ett är att skriva m EBH, steg 2 EBH WS sm skulle kunna förenklas ch effektiviseras betydligt, steg 3 uppdatera Reprting Services till senaste versin, samt att låta rapprter nyttja samma data-access (via EBH WS) sm EBH för att ha samma data/frågr avsett m rapprt tas ut, eller data visas i gränssnittet. Estimat tidsåtgång (steg 1): tim Rättigheter/Behörighetsnivåer Rättighets- ch behörighetsstrukturen är relativt enkel, med 6 lika behörighetsrller. Med eknmi-funktinerna nu inaktiverade, mfattas endast bjekt ch dkument kpplade till bjekt av åtkmstkntrll. Alla kan se ch söka alla bjekt, se ch söka dkument kpplade till bjekt tillhörande egen rganisatin, samt ta ut rapprter, medan endast vissa grupper kan skapa/ändra/ta brt bjekt/dkument. Begränsningen utgörs alltså av tillgång eller icke tillgång till redigeringsverktyg för bjekt/dkument, samt åtkmst till dkument baserat på rganisatinstillhörighet (kmmun, Länsstyrelse, Naturvårdsverket) vilket bör vara en relativt enkel styrning att implementera.

22 1.5 Mdernisering av kd Dagsläge EBH är, under EPiServer, utvecklat på Micrsfts ASP.NET Web Frms-teknik. Idag bygger EBH på Micrsft.net-plattfrm versin 4.0, medan webbservice (EBH WS/databasåtkmst) bygger på Micrsft.net versin 2.0. Aktuell versin av Micrsft.net-plattfrmen är Användargränssnitt skapas utifrån fördefinierade kmpnenter sm, när systemet körs, mvandlas till den HTML-kd sm bygger upp en sida med dess layut ch innehåll i webbläsaren. Detta har tillåtit snabb utveckling på bekstnad av flexibilitet, då man förlrar full kntrll över hur den resulterande HTML-kden (ch därmed presentatinen i webbläsaren) blir. Web Frms intrducerades samtidigt med ASP.NET-plattfrmen sm ersatte klassisk ASP i början av 2000-talet. Under huven används View State, en teknik för att hålla reda på vilka förändringar användaren gör i en sida. Om applikatinen inte specifikt talar m vad sm är relevant att hålla reda på i en sida, kan detta View State bli mycket strt, någt sm påverkar prestanda när det skickas fram ch tillbaks mellan webbläsare ch server varje gång en sida öppnas eller sparas. Sm exempel är den ttala strleken för sidan Objektsammanfattning i visa-läge ca 400 kb, varav View State utgör dryga 3/4. Med bra prestanda på datrer ch nätverk blir användarupplevelsen inte nämnvärt påverkad, men med begränsningar i prcessrkraft ch nätverk (så sm surfplattr ch andra mbila enheter) påverkas användarens upplevelse av hur effektivt arbetet utförs av den mängd data sm ska överföras ch bearbetas. Web Frms bygger till str del på pst back, d.v.s. användaren öppnar ett frmulär, fyller i infrmatin, klickar på Spara varpå sidan laddas m i sin helhet (alternativt en ny sida laddas). Det finns en hård kppling mellan användargränssnittets kmpnenter (textrutr, knappar, rullgardinsmenyer mm) ch bakmliggande kd, vilket innebär att användargränssnittet inte kan förändras utan att bakmliggande kd ckså uppdateras. Utveckling sker med Micrsft Visual Studi 2010, ch källkd hanteras i SVN Framtid Ett ledrd vid webbutveckling idag är Respnsiv Design, d.v.s. sidans layut, utseende ch funktin anpassar sig till den webbläsare (ch framför allt skärmstrlek) sm används för att använda systemet. På så sätt kan samma webbapplikatin användas avsett vilken typ 63 Apache Subversin Ett system för versinshantering av källkd

23 av enhet (datr/surfplatta/telefn) sm används. Detta kräver dck full kntrll över den HTML-kd sm skickas till webbläsaren på en nivå sm Web Frms inte tillåter. Respnsiv design berörs ckså i förstudien Kncept Webb 2.0, på Länsstyrelsens uppdrag utförd av Meridium AB, 2014 Clean Cde är sedan en tid ett tankesätt sm genmsyrar prgramutveckling både hs Altran ch hs de flesta större IT-knsulter. Kden ska, förutm att lösa sin uppgift, ckså vara skriven på ett sådant sätt att den ska vara självförklarande, lätt att förstå, lätt att underhålla ch lätt att förändra. Fördelen är lägre förvaltnings- ch underhållskstnader, samt krtare startsträcka när nya utvecklare ska sätta sig in i befintlig kdbas. Med generella, standardiserade kdbiblitek (ex jquery, Angular m.fl.) underlättas utvecklingen av klient-lgik så sm validering av inmatning på ett sätt sm fungerar på en känd mängd webbläsare. Man talar idag ckså mycket m ne page applicatins, där allt infrmatinsutbyte mellan klient ch server sker i bakgrunden utan mladdning av sidan. Webbapplikatinen upplevs då mer sm ett vanligt datrprgram än någt man kör i webbläsaren. Idag sker nyutveckling på Micrsfts ASP.NET-plattfrm företrädesvis med arkitekturen MVC (Mdel View Cntrller). Den stra fördelen är separatin f cncerns, d.v.s. användargränssnitt, data-mdell ch lgik är tydligt separerade, ch kan fungera fristående från varandra. Denna separatin tillåter så kallad testdriven utveckling (TDD 4 ) ch underlättar autmattestning i allmänhet. Med autmatiska tester blir riskerna för väntade följdprblem vid förändring/uppdatering av befintlig kd mindre, ch mfattningen av manuella tester av hela systemet vid varje förändring minskas. Utvecklaren ges full kntrll över användargränssnittets utfrmning ch kan helt fritt ändra alla aspekter av användargränssnittet utan att bakmliggande kd förändras. Berende på skärmstrlek kan exempelvis helt lika vyer av samma data visas i webbläsaren (till exempel m det finns krav sm inte är möjliga att uppfylla med respnsiv design). I jämförelse med Web Frms tar nyutveckling med MVC generellt längre tid, (Web Frms beskrivs fta sm en arkitektur för RAD 5 ) men sett över ett längre tidsperspektiv där även förvaltning, underhåll ch vidareutveckling vägs in, är uppfattningen att en MVCapplikatin ger en lägre ttalkstnad än mtsvarande Web Frms-applikatin. Utvecklingsmiljön bör uppgraderas till Visual Studi 2013 med källkdshantering på Länsstyrelsens Team Fundatin Server Online. Samtliga systemdelar (EBH, EBH WS, EBH 4 Test Driven Develpment Först skrivs prgram för att testa kden, sedan själva prgrammet 7 5 Rapid Applicatin Develpment Snabb applikatinsutveckling

24 API) bör uppdateras till samma versin av.net-plattfrmen (4.5) för att kunna hanteras inm samma lösning. Mina tankar kring detta är kmmunicerade med lösningsarkitekt på Länsstyrelsernas ITenhet, sm kmmer att kmmentera efter nästa veckmöte för länsstyrelsernas ITarkitekter, Eventuellt kan denna förstudie behöva kmpletteras när jag fått infrmatin från detta möte Tillgänglighet Länsstyrelsens riktlinjer för webbtjänster gäller även för interna verktyg. Med tanke på kmmunernas tillgång till EBH-stödet, räknas dessutm EBH-stödet då sm externt, även m det inte är publikt. Webbaserade system ska uppfylla tillgänglighetskrav, samt följa standarden WCAG 6 2, nivå AA. Vid ny- ch vidareutveckling av EBH-stödet måste hänsyn till detta tas. Dagens EBHstöd uppfyller inte mer än undantagsvis riktlinjerna i WCAG. Utan en ttal mskrivning av användargränssnitt (ch därmed bakmliggande kd) är det inte möjligt att leva upp till de krav Länsstyrelsens riktlinjer för webbtjänster ställer. 1.6 Kmpatibilitet med andra/senare webbläsare, tuchskärmar, små skärmar Internet Explrer 11versin EBH-stödet fungerar generellt väl med IE11 m man brtser från vissa ksmetiska skillnader jämfört med IE9, så sm typsnitt, strlek, fet-stil mm. Rapprt-genereringen klagar ibland (sällan) över ett skript sm tar lång tid att köra men visar till slut rapprten m man väljer att inte avbryta körningen Ggle Chrme versin m Ksmetiska skillnader (typsnitt, strlek mm), men all funktinalitet tycks vara på plats, ch fungera sm förväntat. Inga skript-varningar. 86 Web Cntent Accessibility Guidelines

25 1.6.3 Firefx versin Sm i Crme ch IE11 fungerar EBH-stödet över lag väl. Ksmetiskt ligger utseendet väl i linje med det vi är vana vid. Rapprtgenerering tar tid, ch ett skript sm är en del av rapprten tar, precis sm för IE11, så lång tid att webbläsaren varnar: Detta skript är sannlikt en del av Reprting Services, ch därmed utm utvecklarens kntrll Pekskärmar/surfplattr/telefner För pekskärmar finns speciella hänsyn att ta; Så kallade Muse Over-effekter så sm hjälptexter/tltip eller rullgardinsmenyer sm vecklar ut sig när muspekaren vilar över en yta stöds inte alls, ch knappar, menyer ch andra kmpnenter på sidan måste generellt göras prprtinellt större, för att underlätta användandet. På små skärmar måste fta innehållet stuvas m för att ge en bra användarupplevelse. Delar på sidan sm på en datrskärm kan ligga sida vid sida måste på en telefn placeras under varandra. 7 Detta berörs ckså i förstudien Kncept Webb 2.0 Berende på plattfrm (Andrid, IOS, Windws Phne för att nämna de största) förväntar man sig ckså ett visst grafiskt utseende ch navigatinssystem, sm fta skiljer sig markant från hur en webbapplikatin för datrer är gjrd. Det finns inga möjligheter att anpassa EBH för pekskärmar/surfplattr/telefner utan att skapa ett helt nytt användargränssnitt, ch därmed till stra delar ny bakmliggande kd. Berende på förväntad publik, utfrmas fta nya webbplatser nu enligt principen Mbile First, dvs. man börjar med en mycket enkel webbplats sm alla webbläsare ch enheter kan hantera, ch bygger på denna enkla webbplats med design, funktiner ch finesser i lika nivåer berende på vad webbläsaren kan hantera. Detta sm kntrast till att börja 97 Se Mdernisering av kd