Page Comparison

...

• Utvärdera och beskriva möjligheterna att bedriva utveckling i applikationsramverket “Open ePlatform” Open ePlatform för en tredje part

• Att förstå förutsättningar för att säkerställa kontinuitet vid en krishändelse hos befintlig leverantör (Nordic Peak) som en uppföljning av tidigare genomförd analys 2019:

...

Den tekniska utvärderingarna är utförda av en senior Java-utvecklare och återger dennes erfarenheter och åsikter om ramverket och dess potential.

Sammanfattning

1. Utvärderingen visar att vi står i stort sett i samma läge som analysen 2019 ur ett tekniskt och beroendeperspektiv

2. Vi bedömer att det inte går för en tredje part att bedriva utveckling av Open ePlatform utan här finns ett totalt beroende till Nordic Peak

3. Vi bedömer dock att Sundsvalls kommun och eSamverkan-kommunerna, med vår interna drift av Open ePlatform skulle kunna ta över och bedriva utveckling vid en krishändelse hos Nordic Peak under förutsättning att vi har tillgång till senaste version av källkod (se nästa punkt). Detta skulle dock innebära att vi skapar en egen version av Open ePlatform samma tid som vi börjar bedriva utveckling och tappar då möjligheten allt eftersom att dela utveckling med övriga kommuner. Vid krishändelse måste vi dock primärt se till våra egna kommuners perspektiv.

4. För att öka förutsättningar för kontinuitet vid kris behöver vi upprätta en rutin där vi har ständig information om vilket repo/vilken branch som vår produktionsinstans kör, inkluderat information om varje dependency som finns till tredjepartsbibliotek. Utöver detta behöver vi ha tillgång till all denna källkod i korrekt version för varje produktionsrelease.

   1. Exempelvis genom att varje release till oss medföljs av en överföring av källkod till vår SVN eller i en ZIP-fil

Actions

• Upprätta en dialog med Nordic Peak om att säkerställa rutiner och tillgång till källkod för varje release (punkt 4 i sammanfattningen)

• Informera eSamverkan om resultatet

• Informera användarföreningen för Open ePlatform om resultatet

Bakgrundsinformation

För att visa transparens och ge läsaren en möjlighet att förstå de förutsättningar utvärderaren hade inför denna utvärdering, vill vi understryka att denne helt saknade tidigare erfarenhet av Open ePlatform. Detta var dennes första kontakt med applikationsramverket.

...

Detta demo-projekt ser vid en första anblick ut att vara en referensimplementation/instans av Open ePlatform. En beskrivning av hur man kommer igång finns att läsa i dokumentet “Open ePlatform – Dokument för utvecklare”.

I texten nedan återges upplevelser och erfarenheter kring arbetet med att sätta upp demo-projektet. Både vad avser själva miljökonfigurationen, men även intryck av kod, struktur, ramverk, etc. i Open ePlatform.

Det är möjligt att vissa saker som tas upp i texten innehåller felaktigheter, att det finns kod som inte har setts eller att arbetet med att sätta upp demo-projektet inte är helt korrekt utfört. Dokumentet “Open ePlatform – Dokument för utvecklare” har dock följts så långt det bara är möjligt och nedan återges erfarenheterna utifrån det.

...

För att få igång detta är man dock varit tvungen att importera följande projekt (bild från utvecklingsmiljö) Bild-3.

Utvärderarenhar aldrig varit med om att en webbapplikation kräver denna mängd av Eclipse-projekt för att fungera. Det känns faktiskt helt bisarrt och man kan inte sluta förundras över valet att inte gå över till Maven, Gradle eller liknande verktyg. Inte ens i utvärderarens dagliga arbete med utveckling av microtjänster (som över tid kan bli många till antalet) har utvecklingsmiljön haft detta utseende.

...

• Blandning av presentationslogik och affärslogik. Bilder, HTML-sidor, css-filer, etc. ligger blandat med Javakod (se: bild-1)

• SQL (för databas-operationer) ligger inbäddat i javakoden. Det har länge varit praxis att istället använda persistence-API:er, t.ex. JPA. (se: bild-2)

Eftersom det är lätt att låta sig färgas av sina egna bestämda uppfattningar och åsikter när kodkvalitét skall bedömas, valdes att öka objektiviteten genom att låta utföra en kodanalys med verktyget SonarLint. Detta verktyg analyserar koden och rapporterar “code smells”, sårbarheter, buggar och övriga avsteg från god programmeringssed.

...

Resultatet får tala för sig självt och finns att ta del av i bifogad Excel-fil: sonar-issues.xlsx.

Tester

Även om det givetvis går att arbeta med kodstandard av lägre kvalitét upptäcktes saker som är mer besvärande. Den viktigaste av dessa upptäckter är att inbyggda enhets- och applikationstester helt saknas (utifrån vad som går att se). Detta gör att man funderar över följande:

...

Efter att ha bekantats med Open ePlatform under några dagar, ser vi problem med att införliva utveckling av denna produkt av en tredje part, i t ex API-teamen. Problemen bottnar i att följande saknas:

...