Tilstades
- fhl
- jbr
- hamar
- jokim (ref)
Sak 1: Forventningsavklaring [diskusjon]
Vi tek ein runde på kva forventingar folk har, og korleis vi ønsker å køyre prosjektarbeidet.
Ønskeleg å ikkje planlegge så mykje.
Fordel å få prototypa applikasjonen når vi spesifiserer, elles vert det vanskeleg å vite om vi spesifiserer noko som fungerer. Ønskeleg å sette av tid til dette no i prosjektet.
Joakim prøver å gjere planlegginga og det prosjektmessige effektivt, men vi kan ikkje unngå det heilt. Treng noko planlegging og kontroll.
Sak 2: Sjekklista for utvikling [informasjon]
UAV har ei sjekkliste for gjennomføring av utviklingsaktiviteter som prosjektet skal følge. Sjå også oppfølgingsdokumentet for dette. Vi går kort gjennom det, så alle kjenner til krava. Juristane har bedt om juridiske vurderingar tidleg.
Kan vi sette folk på nokre av punkta?
Kommentar til sikkerhets- og juridisk vurdering: Kan ikkje begynne på det før vi har eit løysingsforslag.
Er for tidleg å snakke om det, ser på det seinare.
Sak 3: AWS [diskusjon]
Kom inn forslag om å køyre eValg i AWS, og er ønskeleg å legge dette til i prosjektforslaget. Er dette ok, så lenge vi oppfyller juridiske krav?
Kommentar om at det er lite betryggande at det køyrer i utlandet, sjølv om lovleg.
Praktiske utfordringar: Korleis logge til logstash og statsd når vi køyrer i utlandet? Plutseleg opner vi opp for utverda. Spesielt statsd går på ip-adresser, som fint kan endre seg i AWS med mindre vi betaler for faste adresser.
Ikkje nødvendig å køyre testing i AWS heller, kontormaskina er bedre for slikt.
Kan ta tid å få kompetanse på AWS.
AWS gir oss ikkje noko ekstra verdi, og vil koste både for køyretid og arbeid for å sette seg inn i det. Det hadde vore artig å holdt på med, men har ikkje hensikt i prosjektet. Meir hensiktsmessig at vi ser til at applikasjonen køyrer container-basert, slik at det er mulig å køyre den i AWS.
Konklusjon: Vi tek ikkje med AWS i prosjektet. Vi ser til at løysinga køyrer container-basert og cloud-ready, men ser ikkje spesifikt på AWS.
Sak 4: Teknisk løysing [diskusjon]
Vi diskuterer dagens eValg-løysing, og kva vi ønsker å gjere. Ei konkret oppgave i prosjektet er å avklare om vi skal bytte ut løysinga med ei heilt anna. Kva innsikt treng vi i løysinga før vi avgjer dette?
Ny løysing eller gjenbruk?
eValg 3.0 kan fint utviklast i den gamle applikasjonen, men er det hensiktsmessig?
Noko vi veit:
- Vi veit at struts må ut, sidan det ikkje støttast lenger, så må fjerne/oppdatere ein god del javakode (~10'000 linjer).
- Templating i løysinga er ubrukeleg samanlikna med nye verktøy. Bør erstattast med noko meir dynamisk (~7'500 linjer).
- Datamodellen må skrivast ein del om. (Helst ikkje java grunna interface.)
- Løysinga bruker berre gamle ting i java, så har ikkje nytten av alt nytt, fint og enklare, bl.a. ny syntaks.
- Løysinga er virkelig ikkje skreven for å kunne unittestast! Krever mykje omskriving.
Konklusjon: Vi bør skrive om løysinga til noko nytt og bedre. Det er for mykje jobb å få eksisterande løysing opp til noko meir moderne.
Førsteutkast løysingsforslag
Vi diskuterte vidare korleis delane i ny løysing bør fungere.
- Diskuterte om bør bruke SQL eller annan db-modell. Er mykje variasjonar i modellen, så kanskje noko document-store-aktig passer bra.
- Ser for seg to-tre data-backends: ein for valg og ein for stemming, og ein for manntal.
- Ang. kryptering. Kanskje bruke noko anna enn GPG for krypteringa? Bør sjå kva som har best støtte i nettlesaren.
- Hadde vore ein fordel å spesifisert opp opptellingsfunksjonaliteten først, og så implementert den, og så sett på dei andre komponentane (manntall- og valg-microservice). Er ei utfordring at prosjektet skal spesifisere opp alt no, og så kjem implementasjonen til neste år.
- Vi ser at det ikkje er nok med fire sprintar til å implementere heile, nye applikasjonen. Må ha fokus på kva som er nice-to-have.
- Korleis skal autorisasjon fungere? Snakka om Feide connect, men usikkert korleis. Har manglar, så ser ikkje lovande ut å bruke det. Må komme tilbake til det.
- UX må komme med innspel om kva data frontend treng rundt valg. Til dømes tittel og beskrivelse av valg, og spesielt data som ikkje er relevant for backend anna enn at det må lagrast.
Ser for seg ei løysing med fem separate tenester (stemme-teneste, valg-teneste, manntall-teneste, logisk eValg-lag og opptellingsmicroservice), samt klientkode for bl.a. dekryptering av stemmer. Mykje er uklart endå.
Korleis gå vidare?
- Må sjekke ut autorisasjon. Fredrik ser på muligheter til neste møte.
- Må sjå på flyten til dei ulike valgtypane, for å sjå funksjonalitet som trengs av komponentane. Data inn og data ut. Treng å lage ein oversikt over dataflyt. Dette trengs også i dokumentet som beskriver applikasjonen. Robert lager ein oversikt til neste møte.
Må sjå meir på blant anna manntall neste gang, og nøkkelhandtering.